Systems and methods for executing business processes over a network

ABSTRACT

Systems and methods for executing business processes over a network. In an exemplary embodiment of a method of executing business processes via a computer network, the method comprises the steps of creating and installing software resources available over a network, browsing a database of software resources using a process model builder to identify software resource definitions, loading the software resource definitions identified by the process model builder to create a business process model comprising the software resources from the database of software resources, mapping inputs and outputs of the database of software resources to allow the business process model to be executed, saving the business process model on a storage medium accessible by the network, and initiating a collaborative business process by loading the business process model into a process interpreter and executing the software resources defined within the business process model.

CO-PENDING APPLICATION

This application claims benefit the failing date of Provisional PatentApplication Ser. No. 60/438,833 filed on Jan. 8, 2003, by Inventor CraigSproule.

FIELD OF THE INVENTION

The present invention relates generally to collaborative businessprocesses and transactions. More specifically, the present inventionrelates to systems and methods for the dynamic creation, generation,integration and execution of business processes and transactions over anetwork.

BACKGROUND

Enterprise software technology has matured to the point where today manyhundreds of thousands of business processes are wholly or partiallyimplemented in software and conducted via communications transactedacross distributed networks. These communications networks may compriseelements of more than one electronic messaging system, to include theInternet, Extranets, Intranets, Local Area Networks, Wide Area Networksand other suitable electronic messaging networks or systems known in theart. The capability to rapidly generate new business process softwarethat can smoothly integrate with pre-existing distributed computingenvironments, software programs, software components, and communicationssystems can greatly enhance the financial advantage, economic value andeffectiveness of the resultant software and the authoring agent.

Traditional application software development has involved businessanalysts undertaking business process reviews, collecting requirements,and collating business rules in order to produce a general design for abusiness system. This general design would be expanded to includesoftware developers who would then create a detailed softwarespecification. This detailed software specification would then be handedover to software engineers to prepare functional and technical designdocuments. A team of programmers and administrators in turn would usethese documents to develop an application that provide a certainsolution. Once complete, the rigorous testing process would commence.This normally includes code testing, component testing, system testing,field and user testing.

Using the traditional approach, the possibility of errors introducedinto the final application due to omissions, inconsistencies,ambiguities or misunderstandings was extremely high. In addition,maintenance and modification of the application may involve, forexample, understanding and modifying code associated with theapplication. This can be difficult due to personnel change, cost, risk,and length of time since the application was developed, etc. All ofthese factors may contribute to unnecessary delay in responding tobusiness needs.

The advent of web-based business-to-business and business-to-customersystems demands an integrated business application development anddelivery environment. Such an environment will allow business to rapidlyand directly implement a custom response to a business opportunity, tofine-tune the custom response as the business learns, and to adapt thatresponse as business requirements evolve. It is, therefore, an object ofthe method of the present invention to enable the authoring andcomposition of business process models, and the resultant real-timegeneration, integration and execution of business applications frombusiness process models with little or no coding, programming orscripting.

SUMMARY OF THE INVENTION

Towards this and other objects that will be made obvious in light of thepresent disclosure, a preferred embodiment of the present inventionprovides an environment, optionally a runtime environment or withruntime environment aspects, for the composition, generation,integration and execution of collaborative business processes andtransactions over a distributed computing-based network.

The method of the present invention optionally enables, in certainpreferred embodiments, a creation of a business process flow by abusiness process engineer or designer that is implemented in a softwareprogram and over a distributed computer network, and wherein theengineer or designer builds an abstraction of the business process insoftware and the software program is generated without software codingor software programming by the designer or engineer.

In a first preferred embodiment of the method of the present invention,the business process designer creates an abstraction of a businessprocess to define the operation and functionality of a softwareapplication by using a computer network browser, such as INTERNETEXPLORER™ web browser. The designer's browser may be located on apersonal computer, a wireless computational device, or other suitablecomputational systems or devices known in the art, and having access toa composer software over the Internet. The designer optionally does notneed or have a client software on the personal computer, but directs thecomposer software solely with the browser and via a communications linkwith the Internet. The designer users the composer to create a graphicalrepresentation model of the logical flow and processing of a targetbusiness process. The designer additionally builds or selects anddesignates data structures, data types, and an organizational structureor structures that inform, enable and/or direct the dynamic activity ofa software application. The designer additionally uses the browser toinform, designate and/or select external software resources, such as webservices made available over the Internet, for access by the softwareapplication. The designer may optionally and additionally format reportsand messages to be provided by the software application. A user may thenuse a suitable user's computational device known in the art to direct asoftware player to generate the application software by employing theinstructions, information, software data structures, software logicmodels, organizational structure, and access to external softwareresources provided by the designer. The user's computational device maycommunicate with the player by means of an interface software, such as abrowser, and via a communications link, such as an Ethernet link, anInternet dial-up link, a wireless link, or another suitablecommunications link known in the art. The player may reside entirelyoutside of the user's computational device. Account access and passwordprotection may be employed to confirm the identity of the user and thatthe user has properly approved access to use the target applicationsoftware. The user may be permitted access at one of a plurality ofaccess levels to more than one application software selected from alibrary of application software programs. The player may then direct theplayer to generate, or instantiate the target software application andfurther direct the player to run the generated application software. Thetarget application software may then be created by the player and thetarget application software will execute. The player may performexternal calls, lay out reports and messages, and use the grammar engineto generate scripts needed to generate the target application software.The first preferred embodiment of the method of the present inventionmay thereby enable a designer and a user without software coding orprogramming to define, create, access and use the target softwareapplication by means of a browser located on a networked computer, and aremotely located composer, software, and other suitable softwareresources and web services known in the art that are available via acomputer network.

A first alternate preferred embodiment of the present invention iscalled Visual Enterprise™ BPI Software Platform (“VE”) and includes theVE Composers™ and the VE Player™. The VE Composer allows a businessprocess engineer/expert/person (terms used interchangeably throughoutthe document) to model, over a network, the processes, rules and datastructures of an entity upon the basis of a plurality of softwareresources. A software resource may be, in singularity or combination,software resource is selected from the group including a database, agrammar rule, a software object, a data structure, a datum, a universalresource locator, a network address, a data type definition, a datapointer or other suitable software elements known in the art.

The VE Player, by a user at run time, then executes in real time themodeled processes, constructs the page layout and accesses relevantdata, according to rules and resources as related within the businessmodel generated by the business process expert. The preferred embodimentdynamically (meaning in real-time) constructs Web pages based on theprocess, rule and data definitions prepared by the process expert. Pagesare constructed only when required, ensuring that the solutions areflexible, dynamic and based upon the most current model revision. Themeans of doing so is the VE Enterprise Interpreter™, which is inside theVE Player. The VE encapsulates a grammar engine that allows theexecutable code to be dynamically created without syntax or scriptingerrors. The preferred embodiment relies upon four main principles ofapplications development: process, data, rules and calendar. The modelgenerated by the VE Composer accords with the business processesemployed by a relevant organization, and may optionally model workflow,work allocation and assignment, process escalation and administration.Modeling data may comprise defining each data attribute, includingproperties such as its type, e.g., numeric, text, or date, as well asdefining associations between attributes. Business policies arereflected in the rules that govern the capture and maintenance of datawithin the context of each step of a process. The preferred embodimentconforms to at least one time zone, the business/working hours of one ormore location, the public holidays observed in designated locales andany other temporal events relevant to the organization's operations.

In one optional aspect of the invention, a method of developingapplications is disclosed. Using a communications network browsersoftware, such as INTERNET EXPLORER™ computer network browsing software,or another suitable browser known in the art and suitable for a selectedcommunications network, a business process expert develops anapplication solutions for an organization by composing a businessprocess model over a computer coupled to a network. The applicationdevelopment environment includes a graphical user interface, such as abrowser graphical user interface, that provides, or provides access to,tools, software modules, software components, data sources, web servicesand other suitable software resources known in the art, for the businessprocess expert to define and interweave data structures, rules,attributes, activities, organization, policies, workflow for processesand applications for an entity and using optionally includingpre-existing software components related to the entity. Models arerelated to the organization in a hierarchical structure. Models mayinclude business rules information, calendar information, datainformation and user information associated with the entity or otherentities. An entity may be a person, a corporation, a department, apublic or private agent or agency, an association, a society, a softwareprogram, or other suitable identity or collective known in the art.Using drag and drop, point and click or voice response actions, abusiness process expert designs all the elements of the applications ina fashion that models the way the business establishes, or wishes toexplore managing and controlling a particular set of business processes,activities or transactions.

In certain alternate preferred embodiments of the method of the presentinvention, a user, engineer, or business process engineer may integratea first business process software program with a second business processsoftware program, wherein the first business process software programand the second business process software program communicating via acomputer network. Preferred embodiments of the present invention of thistype may comprise (1.) interrogating the second business processsoftware program via the computer network to determine how a messagecontaining data may be structured in order to enable the second businessprocess software program to accept the data, (2.)) detecting a set ofdata that the first business process software program may provide to thesecond business process software program, (3.) structuring a message fortransmission to and acceptance by the second business process softwareprogram, the message containing the set of data, and (4.) transmittingthe message to the second business process software program via thecomputer network.

Other features of the present invention will be apparent from theaccompanying drawings (found in the attached VE Blueprint) and from thedetailed description, which follows.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example in the followingdrawings in which like references indicate similar elements. Thefollowing drawings disclose various embodiments of the present inventionfor purposes of illustration only and are not intended to limit thescope of the invention.

FIG. 1 is an example, from the VE Composer™, of the flow of a businessprocess as seen in the VE Composer. A business process can be of anytype, of any length and of any complexity.

FIG. 2 is an example of linking activities. Linked activities can be ofany complexity, including, but not limited to, internal, external,automated, launched, messaged, reported and web services types ofactivities.

FIG. 3 is an example of a data set. Data sets can be text, numeric,date, time span, document, or Boolean and can be accessed bothinternally and externally to the preferred embodiment.

FIG. 4 is an example, from the VE Player™, of one-to-one (Invoice toDealer) and one-to-many (Invoice to Line Item) associations within anactivity.

FIG. 5 is an example of the VE Player's ‘In Tray.’ The Player alsoincludes an Out Tray, New Processes, Reporting and Administration.

FIG. 6 is an example New Process Explorer.

FIG. 7 is an example of the VE Composer page. The VE Composer comprisesof a main menu, an explorer or navigation section and a workspace wherethe process models are created and maintained.

FIG. 8 is an example of the process explorer in the VE Composer.

FIG. 9 is an example of the VE Composer's process workspace.

FIG. 10 is an example of Business Rule Composer Definition inside therules wizard, which is inside the VE Composer.

FIG. 11 is an example of the Organizational Calendar, inside the VEComposer. The calendar consists of Working Hours, Holidays, Date Eventsand Time Events, all in multiple time zones.

FIG. 12 is an example of a Process Category Definition.

FIG. 13 is an example of defining a User Input Activity.

FIG. 14 is an example of Package Associations.

FIG. 15 is an example of Attribute Definitions.

FIG. 16 is a sample business rules created with the VE Composer.

FIG. 17 is an example of an Activity Page as the Activity Page wouldappear in the VE Player.

FIG. 18 is an example of interaction between 2 processes.

FIG. 19 is an example of Activity/Package definitions with relatedattributes.

FIG. 20 is an example of Activity/Package definitions.

FIG. 21 is an example of an activity executing in the VE Player.

FIG. 22 is a sample of a XML Activity Data Fragment.

FIG. 23 is an implementation of an alternate preferred embodiment of themethod of the present invention in a networked computing environment.

FIG. 24 is an implementation of another alternate preferred embodimentof the method of the present invention in a networked computingenvironment.

DETAILED DESCRIPTION

In describing the preferred embodiments, certain terminology will beused for the sake of clarity. Such terminology is intended to encompassthe recited embodiment, as well as all technical equivalents, whichoperate in a similar manner for a similar purpose to achieve a similarresult:

-   -   Processes (see FIG. 1): A Process is a collection of related        activities in a defined workflow that, once completed, execute a        specific and well defined business objective, process,        collaboration or transaction.    -   Activities (see FIG. 2): An Activity is the smallest action        element of a process. An Activity is normally associated with        one step in an overall process. An Activity can be user defined,        automated, emailed, reported, queried, messaged, remote, define        an event or launch a new process.    -   Packages (see FIGS. 13 and 14): Packages are similar to database        tables. Packages are associated in two ways: 1) independent        packages can be loosely associated in a relatively ad hoc way,        as required for specific processes, and 2) packages are        associated to the point of dependence, for example line items on        an invoice. Here the dependent package would be defined as a        Sub-Package. Data in a Sub-Package cannot exist independently of        the package instance Data is dependent upon. When the ‘parent’        is deleted, the sub-package data is removed as well.    -   Attributes (see FIGS. 3, 15 and 20): Attributes are similar to        columns in a database table. An attribute defines a collection        of values where each instance in the collection conforms to the        definition provided by the attribute. Each attribute has a        number of properties, such as whether the attribute represents a        date, a number, text, etc; how it should be formatted on the        page and in reports; input control options, etc. Attributes are        defined in collections called Packages, and Packages are        associated with each other in various ways. Each Attribute        defines the name, data type, size and other properties of the        values that will be stored against an Attribute. When a package        instance is created, attribute values are created and stored        with a reference back to the package and the attribute within        the package. A single package instance consists of one set of        values. There can be any number of instances of a given package.    -   Organization (see FIGS. 11 and 12): An Organization is the        structure in which the model and the associated application (a        collection of processes) executes. An organization may        comprise: 1) Engineers, those authorized to design and modify        the system, 2) users, those authorized to use the system, 3)        Directory; of which a collection of packages and attributes        designed for global purposes for the enterprise, and 4)        Calendar, which determines the working hours, holidays, etc. of        each area of operation for a business entity or entities.    -   Rules (see FIGS. 10 and 16): Business rules are the policies,        regulations and constraints governing the way an organization        carries out organizational operations. VE is concerned with        those business rules that are in some way related to, or impact        upon, the business processes being developed. For example: “the        discount must be less than 10%”, or “a purchase order form must        include at least one item”.    -   Integration: The preferred embodiment supports 5 integration        methods:        -   External Components: VE allows standard COM components to be            utilized as part of the native business rule grammar. This            is achieved by registering a given COM component using the            Composer interface. VE examines that methods implemented by            the components and maps all parameters to native VE            attribute types. The methods are then dynamically added to            the business rule grammar. At business rule execution time,            VE performs the necessary interfacing required to make            remote procedure calls to the relevant external components.        -   Remote Data: VE comes standard with a custom web service            that can be deployed against any data source supported by            the ActiveX Data Objects (ADO), which includes any data            source that has an ODBC driver. Through VE accessing the web            service, engineers are able to define “remote packages”            based on tables in data sources supported by the web            service. Such “remote packages” are treated as if they were            native data of the given VE solution. The business rules            layer performs all the necessary mechanics to update the            data source taking into account the data source's            referential integrity.        -   XML Messages (see FIG. 22): VE allows custom XML (eXtensible            Markup Language) messages to be exchanged with external            systems via the Internet. An engineer can construct            definitions (i.e. using the XML Mapper interface) that            describe how to interpret incoming XML messages and convert            them to native VE packages and attributes, and vice versa.            Again, from the engineer's perspective the XML is treated as            if the XML code were native VE data, with the business rules            layer performing all the mechanics necessary to convert            between the defined XML, schema and VE packages and            attributes.        -   SOAP Messages: VE supports both the construction of external            SOAP (Simple Object Access Protocols) requests and the            ability to respond to external systems making SOAP requests            on VE. At its simplest, SOAP identifies a request XML            message schema, a response XML message schema, and the            mechanism for the communication of these schemas. Using the            previously described XML mapping interfaces, engineers            define the structure of both incoming and outgoing SOAP            requests and treat the schemas involved in these requests as            if they were native VE packages and attributes. Again, the            business rules layer performs all the mechanics necessary to            construct, interpret and dispatch SOAP requests.        -   Web Services: Visual Enterprise supports both the            consumption of external web services and exposing Visual            Enterprise processes as web services. The consumption of an            external web service is essentially the same as making a            SOAP request. The only difference is that an engineer can            use the composer to search a UDDI (Universal Directory and            Discovery Interface) registry to find the required web            service.

In certain alternate embodiments of the method of the present invention,a user, engineer, or business process engineer may integrate a firstbusiness process software program with a second business processsoftware program, wherein the first business process software programand the second business process software program communicating via acomputer network. Preferred embodiments of the present invention of thistype may comprise (1.) interrogating the second business processsoftware program via the computer network to determine how a messagecontaining data may be structured in order to enable the second businessprocess software program to accept the data, (2.) detecting a set ofdata that the first business process software program may provide to thesecond business process software program, (3.) structuring a message fortransmission to and acceptance by the second business process softwareprogram, the message containing the set of data, and (4.) transmittingthe message to the second business process software program via thecomputer network.

In an alternate embodiment of the present invention, a system and methodfor application development is implemented. An application developmentenvironment, optionally a runtime environment, is provided to allow abusiness process engineer to define and document business processes,data definitions, business rules, transactional, organizational andcalendar information. The business process engineer accesses theapplication development environment, the VE Composer, via a networkusing a network browser software, or browser to develop applicationsusing one or more business processes consistent with the datadefinitions, the business rules, workflow and policies and the calendar,event, trigger and organizational information without programming,coding or scripting.

The following detailed description sets forth numerous specific detailsto provide a thorough understanding of the invention. However, those ofordinary skill in the art will appreciate that the invention may bepracticed without these specific details. In other instances, well-knownmethods, procedures, protocols, components, algorithms, and methods havenot been described in detail so as not to obscure the invention.

A first alternate preferred embodiment of the present invention, or VE,provides business process engineers with an environment, optionally aruntime environment, to define and document business processes, datadefinitions, business rules and a calendar of events. The VE comprisesan environment that includes the VE Composer (see FIGS. 7 and 8). As theComposer has a Web-based browser interface, the business processengineer can use VE from anywhere. All the business process engineerrequires is a computer with access to the Internet.

The information recorded by the engineer is used directly to constructthe solution, without the need to translate from specifications tosource code and without the need for a parsing or compilation. The VEComposer allows the engineer to structure and layout components in afashion that models the way in which the organization might previouslyhave documented the organizations processes and rules. All of thisinformation can be viewed by management or other interested parties in atransparent manner, as opposed to being hidden away somewhere incomputer code.

Further, the VE Composer provides a graphical user interface (GUI),delivered over a network, that allows the business process engineer orperson to record all the information pertinent to an organization andrelevant procedures and policies, including, but not limited to,organizational structure, calendaring, workflow, rules, organizationdata definitions, delegation of authority, security and corporate legalstructure. The information is used to develop collaborative businessprocess applications and transaction based systems, such as supply chainor customer relationship management, for the organization. Theinformation is used to model the business in a fashion that reflects theway the organization establishes workflow processes and business ruleswithout need for a technical build process (e.g., parsing, compilation,coding or programming). The resultant solution can be viewed bymanagement or other interested parties in the organization in atransparent manner, as long as they have the security to do so.

The VE Player is optionally the environment by which management, staffor other authorized persons of an organization can access the businesssolution developed by the business process engineers (see FIGS. 5 and6). The VE Player interface is entirely Web-based, and is accessed via apre-allocated URL (for example, http://ve.orgname.com). The home page atthis address requires the user to supply a login name and password inorder to gain access to the site. An Administrator with the appropriateauthority creates a login name to grant access to new users. The initialpassword is allocated by VE and communicated to the user via e-mail. Thefirst time the user logs into the site he is required to select a newpassword, which will then be used for all subsequent access to the site.

One of the main optional features of the VE Player is the VE EnterpriseInterpreter™, which is what translates the model into the applicationsolution. The Enterprise Interpreter is a process interpreter and anengine that drives the execution of the processes, activities,attributes and rules of a VE application. The Enterprise Interpreter canrespond to actions taken by a user, such as submitting an activity forcompletion, initiating a scheduled activity at the required time, orresponding to a request from an external process and do so in real time.Once an activity is requested, the Enterprise Interpreter constructs thepage, constructs and executes the business logic, determines whatdatabase calls are needed, makes any external calls necessary and thenexecutes the process and runs the application. To do this, theEnterprise Interpreter includes a grammar engine that allows the VEPlayer to automatically create the software code necessary to run anapplication without syntax or scripting errors.

The Enterprise Interpreter is a multi-threaded environment meaning thatthe Enterprise Interpreter can handle requests or tasks from multipleusers and other sources at the same time. Once that the EnterpriseInterpreter has serviced a request, that the Enterprise Interpreter willsend a response back to the client, including an indication of whetherthe request was serviced successfully or not.

FIGS. 1 and 7 are examples of process models built with the VE Composer.The elements (processes and activities) are related to one another in ahierarchical structure and are used by the business process engineer todevelop applications. Entities are organizations for which theapplications are to be developed. The Engineers are the business processengineers who develop the applications. The Users include management,employees, customers, vendors and partners or other interested partiesof the organization who have been granted secured access to use theapplications developed by the business process engineers. Groups includepositions or roles within the organization against which secured accessto a particular process or activity is granted. The Organizationcalendar (see FIG. 11) provides time zone, working hours, publicholidays, and reporting period information as well as other time-relatedevents relevant to the organization. The Organization Dictionary is atemplate of packages and attribute properties, which is used to createsingle instance definitions that enable standards to the informationcollected by the organization and used across application boundaries.

An application (see FIGS. 17 and 21) may be a collection of businessprocesses, data definitions and business rules, which together reflecthow an organization or particular section of an organization operates.The attribute library (see FIGS. 15, 18 and 19) is a library of dataattributes, which define properties of and relationships between piecesof information collected by the organization. A process is a collectionof related processes used to assist users in identifying the correctprocess to initiate. The process is a series of operations performed tocomplete a particular function of the organization. The activity (seeFIG. 13) is a single operation in the process. The operation may bedefined by the business process engineer as to be completed either by auser or to be automated using, for example, a batch process. The dataattribute, or element, is a piece of information collected by theorganization and is an element of the attribute library. For example(not to be limiting, but for purposes of clarity), information may be acustomer name or an invoice number.

One important factor common to many business solutions is to provide aconsistent user interface. Consistency can be facilitated through theability to define a template of attribute definitions. The attributedefinitions allow the business process engineer to define properties ofan attribute (e.g., data type, default value, whether or not it ismandatory for a user to record a value for the attribute, etc.) Someattribute properties may be specific to a particular data type (e.g.,the number of decimal places, etc.), which is specific to numericattributes. Some attribute properties, while applicable to all datatypes, may have options that are dependent on the data type. For example(not to be limiting, but for purposes of clarity), the optionsapplicable to the format properties of a numeric attribute are differentfrom the options applicable to a date or time-span attribute.

Attributes defined within each organization's template can be groupedinto categories for easy reference. When the business process engineeris creating attributes for a particular application, the attribute'sdefinition can be based on an attribute template. In this way, theattribute inherits properties from the template. The business processengineer may choose to override one or more of these properties. Anyattribute properties that are not overridden will continue to beinherited from the template. For example (not to be limiting, but forpurposes of clarity), a “Currency” attribute template may be defined inthe organization dictionary with the following properties:

Name Currency Data Type Number Control Data Field Default 0 Mandatory NoDecimal Places 2 Display Width 10 average charactersThe business process engineer may then create, as part of theapplication, a “Discount” attribute, which is based on the “Currency”attribute template. All of the properties of the “Discount” attributeare inherited from the “Currency” attribute template. A furtherattribute “Price” may be defined and based on the “Currency” attributetemplate. However, in this case the engineer may choose to override theMandatory property to “Yes” and the Display Width property to 12. Allother properties are inherited from the currency attribute template. If,at a later point in time, the Display Width property of the “Currency”attribute template is changed to eight (8) then the “Discount” attributewill inherit this new value. The “Price” attribute will not inherit thenew value because an old value was overridden. The use of theorganization dictionary can greatly reduce the time required to defineeach of the attributes required for an application. It also means that alater change in requirements relating to the properties of a group ofattributes (such as increasing interest calculations from two (2) tothree (3) decimal places) can be effected with no programming, coding ofscripting.

Each of the attributes may have a number of attribute properties, whichdictate the functionality or rules associated with that attribute. Forexample, the business process engineer can specify that the value of anattribute is selected from one of a list of options. These attributeproperties may include:

-   -   Data Type: text, number, date, etc.    -   Control: This property determines the way in which the value of        the attribute is collected on displayed on the page.    -   Control Options: this includes Data Field, Radio Buttons, Check        Box, and Drop-down List. Depending on the value of other        properties some of these options may not be valid.    -   Options List: This indicates a list of options from which the        user can choose.    -   Extendable Options: This indicates whether the user can add        additional options to the above list.    -   Default: This indicates a default value for the attribute.    -   Mandatory: This indicates whether the user must supply a value        for the attribute.    -   Editable: This indicates whether the user can modify the value        of the attribute.    -   Visible: This indicates whether the attribute's value is        displayed on the page.    -   Report Name: The heading or label given to the values of the        attribute on any report.    -   Description: This is a short description of the attribute, which        is provided to a user when the mouse is positioned over the        attribute.    -   Minimum and Maximum Values: These properties are equivalent to a        business rule that verifies whether the value entered by a user        is greater than a minimum or less than a maximum value.    -   Minimum and Maximum Length (Text Only): These properties control        the minimum or maximum length of text that a user is permitted        to enter.    -   Decimal Places (numeric only): This indicates the number of        decimal places to which the attribute's values are to be stored.    -   Units (numeric only): miles, gallons, dollars, etc.    -   Background and Foreground color: Foreground color is the color        of the text entered by the user while background color is the        color behind that text.    -   Input Format: This property controls the acceptable format for a        value entered by the user. For example, an input format that        specifies two decimal places would prevent the user from        entering more than two decimal places.    -   Output Format: This property controls the format in which values        are displayed. For example, an output format that specified one        decimal place would display the value with only one decimal        place, even though value may be stored to two or more decimal        places.    -   Display Width and Units: These properties control the width        allocated for an attribute on the page. The width refers only to        the attribute value and not the associated label. The units can        be specified as pixels (if extremely accurate sizing is        required), inches, centimeters and average character width        (proportional fonts mean an exact character width cannot be        determined).

This attribute library details the attributes that are collected by theorganization as part of relevant operations. For example (not to belimiting, but for purposes of clarity), the organization may collectinformation about customer names, addresses, phone numbers, purchaseorder numbers, product names, quantities, etc. Each of these attributescan be grouped into packages of related attributes. For example (not tobe limiting, but for purposes of clarity), a “Customer” package would bea collection of attributes related to a customer, including for example,the customer's name, date of birth, gender, etc. A package may alsoinclude a number of sub-packages that are also related in some way. Forexample, an “Invoice” package may contain an “Invoice Item” sub-package.The “Invoice” package would contain attributes for the invoice number,date, etc., while the “Invoice Item” sub-package would containattributes for the name, quantity and price of the product beingpurchased. Attributes in the attribute library may be based on anattribute from the organization's template or they may be defined fromscratch. An attribute that is based on a template attribute may have thesame name as the attribute on which the attribute is based or the namecan be changed as required.

The hierarchical structure (as defined in the Explorer—see FIG. 3)allows the business process engineer a structured method to accessinformation in the organization. For example (not to be limiting, butfor purposes of clarity), to view details relating to an activity, thebusiness process engineer chooses the application, then the processcategory and the process before being able to select the relevantactivity.

When the organization registration is complete, the administrator andany other authorized business process engineers are sent an e-mailmessage containing an allocated organization ID, login name and atemporary password. After this message is received, the business processengineer can log into the VE Composer web site. The first time thebusiness process engineer logs into the VE Composer web site, thatbusiness process engineer may be required to select a new password,which will be used for all subsequent access to the site. Uponverification of the business process engineer's details, the businessprocess engineer is directed to the VE Composer home page. This page isdivided into three distinct areas, including the VE Composer Explorer(see FIG. 8), a process workspace, and a menu bar.

FIG. 7 is a block diagram illustrating components via the VE ComposerExplorer that are available in the composer to allow the businessprocess engineer to develop applications for an organization inaccordance with one embodiment of the present invention. Thesecomponents include the process workflows (see FIG. 9), the attributes(see FIG. 15), the business rules (see FIG. 10) and the organizationcalendar (see FIG. 11). In addition to the above components, othercomponents are also available in the composer and may be used by thebusiness process engineer. For example (not to be limiting, but forpurposes of clarity), the VE Composer includes an administrationcomponent (not shown) to provide security or access control relating tothe business process engineers and the users.

A process workflow includes applications, processes, and activities. Tosupport the applications, the processes, and the activities, thebusiness process engineer design information structures (e.g., datastructures) necessary to record and retrieve the attributes. For example(not to be limiting, but for purposes of clarity), an invoicing processneeds an invoice, and the invoice includes data such as, for example,invoice number, invoice date, line items, amounts, etc.

The attributes are defined by the business process engineer and can beaccessed from any authorized activity in any process workflow.Organizational attributes are defined once and used many times, wherespecific application packages and attributes are used for specificapplication and process solutions. An attribute is a piece ofinformation collected by the organization. Each attribute has a numberof associated properties such as, for example, an attribute type (e.g.,a date, a number, text, etc.), how the attribute is to be formatted on apage and in reports, input control options, etc. The attributes aregrouped together into packages that clarify the use of one attribute inrelation to the other attributes as described above. The values of anattribute (e.g., a customer's name) are recorded using the processes andthe activities defined by the business process engineer. A databasemaintains the complete collection of the values of the attributes. Eachvalue in the collection represents a single piece of information. Forexample, each value of the “customer name” attribute represents onecustomer's name. There is no distinction as to the context of anattribute except for the activity that references that attribute. Forexample, one activity may be defined to record the details of allcustomers, while another activity may be defined to record eachcustomer's purchases. The collection of values of the “customer name”attribute may include a value for each recorded customer as well as avalue for each time a customer has made a purchase. The attributes maybe constrained by the business rules to reflect values allowed by, orimposed upon, the organization. For example (not to be limiting, but forpurposes of clarity), valid invoice numbers have to be in a certainrange or have certain predefined characteristics.

The business rules relate to the capture and maintenance of attributeswithin context of processes and govern the way the organization wants tocarry out appropriate operations. The business rules are designed by thebusiness process engineer to ensure that an application follows thepolicies of the organization. The preferred embodiment incorporates andadvanced rules engine having 4 elements to the rules structure:Categories, constants, functions and properties and is designed tocreate any type of rule, including but not limited to mathematical,trigonometric, statistical, comparatives, numeric, error handling,date/time (down to 1 second intervals), escalation, event, security, andtime span rules. For example (not to be limiting, but for purposes ofclarity), there may be business rules designed to assign default valuesto the attribute, and there may be other business rules designed tomonitor the attribute such that the attribute has valid values and towarn the users when the values are not valid. Another example, a rulecan be applied to an activity such as calculating a result dependant onvariables, or a rule can trigger an event or launch new processes.

The organization calendar provides calendar information including timezones, business/working hours, holidays, reporting periods, etc. thatthe organization operates within. The business rules that enforce timeconstraints operate consistently with the organization calendar. Theorganization calendar is independent of the process workflows in orderto support the organization with offices in different states, timeszones, or countries. This allows a single version of a process workflowto operate, for example, in all of the organization's divisionsworldwide without modification. The process workflows, the attributes,the business rules, and the organization calendar are described in moredetails in the following sections.

FIG. 7 is a block diagram illustrating application and process workflowsin accordance to one embodiment of the present invention. As describedabove, process workflows include applications, processes, andactivities. Within the application are the processes and activities. Theprocesses include a collection of related activities. Each processincludes one initiating activity. The initiating activity may beinitiated either by a user, by an event, or by a remote activity such asanother application or a web service. For example (not to be limiting,but for purposes of clarity), a daily backup batch process is to run at10:00 p.m. each night. The process may be constrained by one or morebusiness rules and determines the order or path in which the activitiesare to be performed. For example (not to be limiting, but for purposesof clarity), some of the activities may be allowed to perform inparallel, while others may not be able to perform until all precedingactivities on an relevant path have been completed.

Process category allows grouping or filing of related processes. Anorganization may have a collection of processes defined by the businessprocess engineer. The process category provides a mechanism to allow thebusiness process engineer and the users to organize and to locate theprocesses without having to search the entire collection of definedprocesses. Using the process categories, the business process engineercan define a filing hierarchy to organize the processes. For example(not to be limiting, but for purposes of clarity), a business processengineer who is developing a sales application for an organization maydefine the following process category hierarchy:

-   -   Customer Relationship Management        -   1. Marketing Campaigns        -   2. Telemarketing    -   Transactions        -   1. Purchasing        -   2. Sales        -   3. Adjustments    -   Maintenance        -   1. Customers        -   2. Suppliers        -   3. Staff        -   4. Departments    -   Reporting        -   1. Weekly Reports        -   2. Monthly Reports        -   3. Year to Date Reports        -   4. Annual Reports        -   5. Ad Hoc Reports            Using the above process category example, all processes            relating to purchasing may be organized under a purchasing            category, etc. To access or to file a process in the            purchasing category, the business process engineer simply            needs to select the transactions category followed by the            purchasing category. Similarly, a user who has been granted            secured access to the purchasing process may initiate the            purchasing process by first selecting the transactions            category.

Process definitions relate to the grouping of related defined activitiesto form a process. An activity is a collection of one or more relatedattribute packages designed to add, update and/or query. Rules may beassociated with an activity in order to validate the attribute or toperform calculations on the attribute. An activity may result in succeedor fail status. The process uses the status of a current activity todetermine which activity or activities are to follow on from the currentactivity. Each activity may be associated with an access authority. Forexample, a manager in the organization has default access to an activitythat involves approving a loan application. The activities that form aprocess are linked or joined together according to a workflow defined bythe business process engineer. FIGS. 1, 4, 5, and 6 illustrate examplesof a loan approval for both the VE Composer and the VE Player. Eachblock in the loan approval process represents an activity. A directionalarrow between two activities represents direction of the workflow. Inthe graphical user interface of the composer, each block in the loanapproval process in FIG. 1 is illustrated using an icon, and thebusiness process engineer can drag and drop activity icons and linkthese activity icons together to form a process or series of processessuch as a message, report, email, automated process, user defined orlaunched process. For example (not to be limiting, but for purposes ofclarity), if the customer equals “IBM” then launch the process called“IBM.”

A remote activity type may comprise a process wherein the attribute isretrieved from or submitted to an external system, remote database orweb service as part of the operations to be included in a process oractivity. The external system may be of any type, including but notlimited to, a business-to-business event, a business-to-customer event,a long-lived collaborative process, or a transaction based system. Amaintenance activity type is where the user can add, modify or deleteattributes in circumstances that may not fall within any formalizedprocess but which, nonetheless, needs to be maintained. An example (notto be limiting, but for purposes of clarity) may be to update acustomer's phone number that may have been entered incorrectly.Maintenance activities may not be used as part of a standard businessprocess with other activity types.

Referring to FIGS. 12 and 16, rules information provides a list of rulesrelevant to the activity, which need to be enforced by an administrator.This is referred to as activity rule. Time criteria information providesproperties that dictate any applicable time constraints (e.g., acompletion deadline, etc.) that are placed on the activity. Accessinformation provides a list of groups and/or users to whom the activityhas been granted access. The groups or users granted access to the firstactivity in a process (e.g., the initiating activity) determine theusers who have the authority to initiate that process. Initiationinformation includes properties that indicate how to determine the useror users to whom the activity should be allocated. E-mail informationprovides details relating to the message that is to be sent. Reportinformation provides details about the report that is to be generated.Automated information provides details about import or export file namesand formats, etc.

Activities that are defined with the remote type (referred to as remoteactivities) allow a process to access attributes or functionalityexternal to the application. This includes, for example, gaining accessto legacy systems, external components (COM+ or EJB), middleware andother organizations' business solutions. Using SOAP (Simple ObjectAccess Protocol) as an underlying infrastructure, external attributesand functionality can be incorporated seamlessly into a process, as ifit was part of the application. SOAP is an eXtensible Markup Language(XML) based protocol that consists of an envelope that defines aframework for describing what is in a message and how to process it, aset of encoding rules for expressing instances of application-definedattribute types, and a convention for representing remote procedurecalls and responses. The information transported via SOAP between theapplication and the remote system includes an XML schema definition thatdefines the list of packages and attributes (universally identifiable)selected by the business process engineer as part of the remoteactivity. Other information transported via SOAP includes business rulesapplicable to the activity that defines conditions to be imposed on theremote activity, and attributes sent to and received from the externalsystem. An acknowledgement scheme is used to indicate success or failureof the operation. For example, the organization may have a legacy systemthat maintains information of all staff working for the organization. Inthis case, a process can be developed to allow a user to access thatinformation in conjunction with other associated attributes. Theorganization may have a legacy system that maintains a general ledger.In this case, activities can be developed to post transactions to thatsystem as part of the processes developed to raise purchase orders,invoices and receipts. When the organization wants to conductbusiness-to-business transactions with a supplier to order stock, aprocess can be developed to allow the organization to place an orderwith the supplier. There may be business rules associated with the orderthat process has to follow. For example, a rule may state that if thecost is above a predetermined limit then the supplier must seekauthorization with the organization before proceeding with the order.The authorization may be obtained by an automated initiation of, forexample, an authorization activity. When the supplier is authorized forthe cost of the order; that authorization would be transported via SOAPto the supplier whereupon the order can proceed. Alternatively, when thesupplier is not authorized, the order is cancelled. It is understoodthat for the remote activity to operate, the remote system or componentalso supports the SOAP infrastructure.

A remote activity may be associated with remote attributes. A remoteattribute is an attribute used to hold the attributes transmitted to orfrom the external or remote system as part of a remote activity. Someremote attributes may need to be stored in a local database while othersmay not. For example (not to be limiting, but for purposes of clarity),attributes defined for customer details stored in a legacy system maynot need to be stored in the local database as this would only duplicatethe attribute for no additional benefit. On the other hand, attributesdefined for a purchase order that is used in a business-to-businesstransaction with another organization would need to be stored in thelocal database.

The business process engineer defines the one or more process views of aprocess. The process view enables the information included in eachactivity of the process to be tailored according to the user who hasaccess to that activity, for both workflow and security reasons. Indefining a process view, the business process engineer defines twocomponents of a view, activity-attributes component and accesscomponent. The activity-attributes component is a selection of theactivities to be included in the process view, and for each activity,which attributes should be visible to a user. The access component is alist of groups and/or users who have been granted access to the processview. It may be noted that being granted access to a process view isdifferent from being granted access to an activity, and may include adigital certificate (signature) as deemed appropriate by the policy ofthe organization. Having access to a process view gives a user access todetails about the history of a process as the process relates to theactivities included in the process view. Having access to a process viewmay not allow the user to complete anyone of those activities. Havingaccess to an activity, on the other hand, does gives a user theauthority to complete that activity no matter which process view isbeing used.

Every process may have one default process view, which includes everyactivity in the process and the attributes associated with eachactivity. A user may have access to more than one process view of aprocess. In this case, the user is given the option about which processview to use when initiating a process or opening an activity (see FIG.5). A process view does not affect the links between activities, therules associated with an activity, the time constraint imposed on anactivity, or other properties assigned to an activity. The process viewcan significantly reduce the number of processes and activities thatwould otherwise be required to develop an application.

One of the defining differences between the present invention andexisting application development environments are the way relationshipsbetween various attributes are defined. Instead of using a standardrelational database model, the preferred embodiment uses a meta-datarepository where attributes and the relationships between attributes aredefined by the context in which the attributes are referenced (e.g.,packages, activities, and processes). This affects both on the storageof data and the way such data is retrieved. For example (not to belimiting, but for purposes of clarity), using the invoice activityexample, with the attributes “Invoice Number Invoice Date”, “CustomerName”, “Customer Phone Number” (for display only), “Customer Address”(for display only), “Multiple invoice item” attributes. This activitymight be used to enter a new invoice. It may be necessary to be able todetermine how and when to retrieve the customer's phone number andaddress. This is done through the definition of packages and keyattributes.

Key attributes refer to attributes that are unique. There may be one ormore attributes within a package or within an activity that are unique.Using the above example, the business process engineer would specifythat the invoice detail attributes were part of the main or controllingpackage. The invoice item attributes would be part of a separate“Invoice Item” repeating package to allow multiple items to be entered.The “Invoice Number” would then be defined as the key attribute for themain package because the “Invoice Number” is unique. The customerpackage and therefore the customer attributes (e.g., name, phone numberand address) would be linked to the main package. This would indicate aone-to-one relationship between a customer and an invoice.

A unique attribute in one activity may be used as key attribute in otheractivities. This is because the unique attribute indicates that theresult set for any related attributes, in a one-to-one relationship,will contain a single value. For example (not to be limiting, but forpurposes of clarity), within an activity to record customer details,both the “Company Name” and “Business Number” attributes may be unique.This means no two companies can have the same name and no two companiescan have the same business number. When defining activities thatreference customer details, for example, the business process engineershould be able to interchange the company name with the business numberwhen required. In effect, the “Business Number” attribute is analternate key for the “Company Name” attribute, and the “Company Name”attribute is an alternate key for the “Business Number” attribute.

An attribute, defined in an activity as being unique, may be analternate key for all of the other unique attributes defined in thatsame activity. This alternate key relationship extends beyond theactivity in which the attributes are defined as unique to any activityin any process.

A search list of activities where both the base attribute and its keyattribute are referenced within the same activity can be formed toretrieve data. The search list can be extended to include any activitywhere the base attribute and an alternate key attribute are referenced.Using the above example, when a “Customer ID” is to be added to the listof customer related attributes, one activity may be defined to collectthe “Customer Name” and the “Customer ID” attributes only (bothattributes defined as unique keys). A second activity may be defined(either within the same process or in another process) to collect the“Phone Number” and “Address”, with the “Customer ID” used as thealternate key attribute. In this case, neither the first activity northe second activity references all of the attributes “Customer Name”,“Phone Number” and “Address”. However, for the purpose of retrieving thephone number and address, the alternate key of the “Customer Name”attribute (i.e., the “Customer ID”) can be used as the link between allof the attributes.

The above approach of using unique key and alternate key to dataretrieval imposes a methodology on the business process engineer thatinvolves retaining a consistent definition of all attributes across allactivities and processes. For example (not to be limiting, but forpurposes of clarity), if a number of address attributes (e.g., street,city, postcode, etc.) were referenced in one activity as a postaladdress and in a separate activity as a property address, no distinctionis recognized. Separate attributes would need to be defined for postaland property addresses so that the definition of these attributes areconsistent in all activities. Thus, in the first scenario an “Address”is sometimes a postal address and sometimes a property address. In thesecond scenario a “Postal Address” can only be a postal address, and a“Property Address” can only be a property address.

For data consistency, only the latest submitted version of anattribute's value is stored. This means that one process may modify thevalue of data created by an activity of a second process while thatsecond process is still in progress. For example (not to be limiting,but for purposes of clarity), suppose an invoice entry process consistsof two activities, one to enter the invoice details and another toapprove the invoice, to be performed by two different users. When a usercompletes the first activity, the invoice details are submitted to thedatabase. Before the next user (e.g., a supervisor) has the chance toapprove the invoice, a third user (e.g., a manager) may run a separateprocess to modify invoice details. If this manager submits changes tothe same invoice before the supervisor begins the approval activity,then these changes will be presented as the invoice details to beapproved. If the supervisor has commenced the approval activity but notsubmitted when the manager submits the changes to the invoice detailthen these changes will not be presented to the supervisor. Notificationis generated (to a supervisor) to indicate that the data has changed sothat the data can be refreshed before approving the invoice. If thesupervisor had approved the invoice before the manager tried to modifythe invoice details it would be left to the business process engineer todecide whether this was a valid activity or not. It may be a businessrule of the organization that approved invoices cannot be modified butcan only be cancelled.

When referencing an attribute of a shared relationship in a businessrule, the attribute is to be fully qualified to include therelationship. For example (not to be limiting, but for purposes ofclarity), an organization may have a business rule that indicates theoffices in which staff work must have a phone number. However, this rulemay not apply to offices in which meetings are held. In this case, thefollowing business rule, for example, would be too restrictive:

-   -   Verify that the Office has a Phone Number.        The rule would need to be qualified such that the relationship        between “staff” and “office” is included, for example:    -   Verify that the Staff Office has a Phone Number.

When referring to an attribute (e.g., in a business rule), the businessprocess engineer may refer to a single value or a set of valuesdepending on the context. For example (not to be limiting, but forpurposes of clarity), in the context of a sales order, when the businessprocess engineer refers to a customer's name, then the reference is to asingle customer. However, when the business process engineer describesthe customers who may place an order, the business process engineer maybe referring to multiple potential customers' names.

In a natural language, the distinction is made by using the plural formof the noun “name” to distinguish between a single name and a set ofnames. The description above also uses an apostrophe to indicate aspecific reference to the name of a customer as opposed to the name of astaff member or supplier. “Customer” would be classified as a package ofattributes and “Name” as an attribute. There is no distinguishing, interms of syntax, between a single value and a set of values. Allattribute values will be part of a set such that a single value issimply a set that contains only one item. This set of values is referredto as an attribute result set.

The packages have a number of package properties, which describe thebehavior of the packages. The package properties may include, but is notlimited to:

-   -   A list of key attributes, which together or in isolation can be        used to uniquely identify an instance of the package. For        example (not to be limiting, but for purposes of clarity), a        customer's name and telephone number might uniquely identify        each customer. This information is critical in ensuring that        when a user chooses a particular entity that there can be no        ambiguity about that choice.    -   A list of search attributes, which are used to assist users when        making a choice from a list of available package instances. For        example (not to be limiting, but for purposes of clarity), to        assist the user in selecting a customer, the engineer might        choose to display the customer's name, date of birth, social        security number, phone number and address. By defining all these        attributes as search attributes enables the user to choose which        criteria to use for the search, e.g. social security number.        Further, where a container package is related on a one-to-many        basis with a sub-package, additional properties are maintained        on the sub-package. These additional properties may include:    -   The order in which the package instances is displayed. For        example (not to be limiting, but for purposes of clarity),        invoice items may be displayed in product code order or in order        of price.    -   A minimum or a maximum number of instances. For example (not to        be limiting, but for purposes of clarity), an organization might        require an invoice to be limited to 10 items or fewer, or not to        be limited at all.

Similar to the attributes having attribute relationships, packages alsosome relationship to other packages. This is defined in packagerelationship. In some cases, a number of different packages and theattributes contained therein have a relationship in common with anotherpackage. For example, a staff member is related to the office in whichhe works. A purchase order is related to an office from which that orderoriginates. A meeting is related to an office in which that meeting isheld. In this case, the “office” package should not be explicitlydefined as a sub-package of each of the “staff”, “purchase order” and“meeting” packages as it would not identify the common or sharedrelationship that exists in each case. Rather, “office” needs to bedefined as an independent package so that it can be referred to, asrequired, across many activities within various processes.

In certain alternate preferred embodiments of the method of the presentinvention, packages that are the subject of shared relationships arefirst defined as packages independently of the packages to which theyare related. When the definition of these packages is done, they can belinked to these related packages. Alternatively, these packages may bedefined implicitly as shared relationships within an activity, based onthe fact they are referenced in common. Shared or linked relationships,by default, are defined as “one-to-one” relationships. This can bechanged to a “one-to-many” relationship by setting a property of thepackage.

A package result set is a set of values for each attribute in thepackage. Each of these sets contain the same number of values, althoughsome of the values may be null or not specified. For example, a customerpackage may consist of a name attribute and a phone number attribute.For each value of the name attribute in the customer, result set thereis a corresponding value for the phone number attribute and vice versa.This does not mean that every customer needs to have a phone number. Forthose that do not have a phone number the attribute value will be null(e.g., empty, blank). A fully qualified attribute name is one thatincludes all of the packages to which an attribute belongs. For example(not to be limiting, but for purposes of clarity), “Customer AddressCity” where City is an attribute of the Address package, which is asub-package of the Customer package. To display fully qualifiedattribute names in business rules would overly complicate the reading ofa rule. If there can be no ambiguity over the package to which anattribute belongs then only the attribute name is displayed, not thefully qualified name. If there may be ambiguity, for example becausethere are two “City” attributes, then it may be necessary to qualify theattribute name sufficiently to remove any ambiguity.

A single attribute may be referenced in any number of differentactivities and processes. When retrieving data, the context in which anattribute is referenced is used to determine the retrieval criteria, andheld in the meta-data repository. In order to retrieve data, arelationship list is determined for each attribute within a process.This relationship list is based on explicit relationships that thebusiness process engineer may have defined, along with any implicitrelationships in the process definition. This defines a relationshipbetween the attributes of both packages.

When searching for related attribute values, more than one instance maybe found that matches with the key value. This set of values forms theresult set for the related attributes, as described above. The attributeresult set may or may not be appropriate for the definition of theactivity within which the attribute is being retrieved. For example (notto be limiting, but for purposes of clarity), a multi-value result setcannot be displayed in a single data field, however it can be displayedin a list or table. In this case, an exception would be raised.

Every activity that allows the user to add or modify attribute values,or that uses business rules to add or modify attribute values does sovia one or more data transactions. The transactions are initiated onlyafter the activity has been validated using the associated businessrules. A transaction is initiated for each package included in anactivity. The transactions are all applied together as a single activitytransaction such that the integrity and consistency of the wholeactivity is maintained. If a single package transaction should fail forany reason then the transactions for all packages in that activity willbe reversed. The transactions do not delete data from the database. Thisis because of the inherent problems associated with deleting data thathas already been referenced by other activities. Instead of deleting thedata, the data is inactivated such that it cannot be referenced in otheractivities. The business process engineer thus does not need to be awareof these transactions because they are automatically controlled andmanaged.

FIG. 16 is a dialog box illustrating different types of business rulesand their relationship with one another in accordance to one embodimentof the present invention. Business rules are the rules, regulations andconstraints that govern the way the organization carries out itsoperations. The business process engineer relies on the business rulesthat are in some way related to, or impact, the business processes beingdeveloped. For example (not to be limiting, but for purposes ofclarity): “the discount must be less than 10%”, or “a purchase orderform must include at least one item”, etc. The business rules aresatisfied at all points in time unless a condition is applied thatspecifically limits the time-span during which the business ruleapplies. For example, a discount may be offered only on invoices raisedbetween Christmas and New Year. This business rule will hold true at allpoints in time, subject to the condition that the discount is onlyoffered between Christmas and New Year. In other words, any attempt tooffer a discount outside of those time constraints is rejected.

The business rules may include attributes business rules to apply toattributes, activity business rules to apply to activities, packagebusiness rules to apply to packages, and core business rules to apply toan entire application. The attribute business rule may be dependent onthe definition of the rule and on the definition of the attributes onwhich the rule is based. The activity business rule may be dependent onthe definition of the activity in the context of which the rule isexecuted. The package business rules and the attribute business rulesmay be automatically associated with each activity in which theattribute or attributes are referenced. The business process engineermay elect to turn off or override such a business rule where it is notapplicable to a particular activity.

One or more attribute business rules may be applied when an attribute issubmitted to the database. For example, the attribute may be submittedto the database in an “update” or in a “modify” activity. Depending onthe value of the attribute, the attribute business rule can validate orinvalidate the attribute. An attribute business rule such as, forexample, “the customer's age is the difference between today and thedate of birth” may not be recalculated every day. However, as soon asthe age is referenced by an activity, either to display the age to auser or to use the age in some calculation, the attribute business rulewill be executed to ensure that the value is correct.

The activity business rules are executed within the context of anactivity. The attribute or attributes to which the activity businessrule refers may or may not be included in the activity. For example, anactivity business rule may be defined against a “Raise Purchase Order”activity, which sets the price of the products being purchased. Theactivity business rule may be:

Assign the Order Item Price=the Product Unit Price

The “Product Unit Price” may not be one of the attributes listed forinclusion on the activity. This is because the “Item Price” will bevisible and to display both attributes would duplicate the priceinformation. If, however, selection of the price is dependent uponcriteria, such as the date, then these criteria will need to bespecified to retrieve the correct result set for the product price. If ahistory of prices existed for each product then criteria would need tobe added to the rule to uniquely identify the correct unit price, asshown in the following business rule example:Assign the Order Item Price=the Product Pricing History Unit Price,where today is between the Product Pricing History Start Date and theProduct Pricing History End Date. When an activity is opened, anyattribute that has already been identified is retrieved from thedatabase. The attribute may have been identified either because it wasrecorded in an earlier activity or because it has been set by anactivity business rule. The attribute may also need to be retrieved fromthe database at other points in time during the completion of anactivity. For example (not to be limiting, but for purposes of clarity),such a situation may occur when the user selects a package instance(e.g., a customer) and the activity definition includes a list ofattributes related to that customer (e.g., Name, Phone Number, Date ofBirth, etc). An activity business rule may also reference attributes notcontained within the activity in order to perform some verification orcalculation.

A business rule may be defined to include one or more rule statements.When there are multiple rule statements, all of the statements need tobe consistent in type. For example (not to be limiting, but for purposesof clarity), a verification statement cannot be defined in a businessrule that also includes an assignment statement. Some business rules mayalso be specified implicitly via an attribute property rather thanexplicitly as a business rule statement. For example, a rule that aninvoice number can be no longer than seven (7) characters may bespecified as a “Maximum Length” property of an attribute. For thisreason, business rule functionality may be provided to the businessprocess engineer as a property of an attribute and/or as a business rulestatement. The fact that a business rule appears as a statement in thisdocument does not preclude that the functionality may be providedexclusively as a property.

There may be different types of rule statements. For example (not to belimiting, but for purposes of clarity), the rule statements may include:

-   -   Logic statement (Passive rule type):        -   Logic statements include variants such as “if . . . then . .            . otherwise”, and “based on the value of . . . if it equals            . . . ”. Repetition variants such as “while . . . do . . . ”            or “repeat . . . until . . . ” are also available.    -   Verification/Validation/Restriction statement (Passive rule        type):        -   Verification or validation statements test a condition and            either report an error or warning or perform some other            specified action. A restriction statement restricts the            available choices that a user can make to ensure the choice            is valid for the particular circumstances.    -   Assignment statement (Active rule type): Assignment statements        can be further categorized into the following:        -   1. Attribute assignment: assign a value or expression to an            attribute.        -   2. Package assignment: set an instance of a linked package            based on specified criteria    -   Action statement (Active rule type): Action statements include        the following:        -   1. “Retrieve” data from the database        -   2. “Initiate” a process        -   3. “Schedule” a process that has been initiated but not yet            commenced        -   4. “Initiate” an activity        -   5. “Schedule” an activity that has been initiated but not            yet commenced        -   6. “Allocate” an activity to a group or a particular user        -   7. “Create” an audit trail        -   8. “Execute” an external process.

A business rule may also be defined with one or more error and/orexception conditions. It is understood that an exception condition setmay include error conditions. These error and/or exception conditionsmay include hardware errors, software errors, internal exceptions andexternal exceptions. The errors and/or exceptions may be raised as aresult of the processing of business rules. A hardware error may occurwhen, for example, a server crashes, when there is insufficient diskspace, when a telephone line drops, etc. A software error may occurwhen, for example, a browser crashes, an operating system hangs, etc.When a hardware or software error occurs, a report of the error isgenerated to allow whatever remedial action to be taken. If possible, anentry is logged and/or an e-mail message is sent to an administratordetailing the nature of the error. Any further processing of businessrules for that activity would be cancelled. The business rules that havealready been processed within the transaction during the processing ofwhich the error occurred, would be rolled back and the transactionalintegrity is maintained for the entire system.

The business rule exceptions can be described as either internal orexternal to an activity. An internal exception is one where control ofthe activity remains with the user allowing the user to modify anattribute or attributes such that the verification rules are met. Anexternal exception is one where the activity is automatically cancelled,and the control flows to an activity scheduler via the failure route forthat activity. An exception may be, for example, a database exceptionwhere a value of an attribute entered by a user does not satisfy one ormore business rules, a time-based exception where an activity is notcompleted within a specified time frame, etc. Most exceptions can bedetected and handled during data entry before the commencement of theprocessing of a transaction. However, if this is not the case then theentire transaction will be rolled back to ensure the integrity andconsistency of the database. In the case of an external exception, thehandling of the exception is taken outside the control of the user towhom the activity was assigned. The business process engineer is able todefine a complete workflow to be followed for each defined exception.This workflow may include, for example, an escalation of the exceptionshould further data or time constraints not be met by the allocated useror users. If both an internal and external exception were to occurwithin an activity, the activity scheduler is allowed to deal with theexternal exception. Any data entered for the activity in error would bepassed to the “Exception” activity, although the data would not becommitted to the database. This allows the user handling the exceptionto either correct that data, where required, or to reset and thenre-enter the data.

The business processes being defined may also require warnings to beissued to users at various stages. This functionality is provided via avariation on the verification/validation business rule definition. Thisvariation would indicate that a warning is to be issued rather thanraising an exception. In this case, processing would continue normallyonce the warning had been issued. Such warnings would be issued beforeany data being committed to the database.

The business rules defined by the business process engineer maysometimes be conflicting or ambiguous. For example (not to be limiting,but for purposes of clarity), one rule may be defined to offer adiscount on certain products at a certain time of year. Another rule maybe defined to offer a discount to loyal customers. In one embodiment,when conflicting and ambiguous business rules are detected, the businessprocess engineer is prompted to redefine the conflicting rules or toclarify the ambiguity. This detection is performed when the businessprocess engineer decides to publish an application. Rules that apply tothe same attribute or attributes are searched. A conflict resolutionform is generated and completed before the application can be published.For example (not to be limiting, but for purposes of clarity), considerthe following separate business rules:

If the Order Date is between Halloween and Christmas Eve and the ProductType is equal to Sports Goods then Assign the Discount=10%

If the Customer Status is equal to loyal then Assign the Discount=5%.

In this example, the “Discount” attribute is assigned to the both thefirst rule and the second rule, and that the conditions applied in eachrule may conflict with one another, resulting in an ambiguity. Thebusiness process engineer may resolve any ambiguity by combining the twobusiness rules into one business rule. The ambiguity may be resolved bydeciding that the “sports goods” discount takes precedence over the“loyal customer” discount. The business process engineer may combine thetwo rules and form a combined third rule as in the following example:

If the Order Date is between Halloween and Christmas Eve and the ProductType is equal to Sports Goods then Assign the Sports Discount=10%

If the Customer Status is equal to loyal then Assign the LoyaltyDiscount=5%

Assign the Discount=maximum (the Sports Discount, the Loyalty Discount)

If the organization wants the discounts to be cumulative then anotherbusiness rule can be formed as in the following example:

Assign the Discount=the Sports Discount+the Loyalty Discount

If the organization does not want to have a discount applied to aparticular purchase order then the result of the above rule would be adiscount of zero.

The business rules may need to be applied at various stages of anactivity or process. In certain circumstances, the business processengineer will determine this stage based on the type or nature of therule. For example (not to be limiting, but for purposes of clarity), thebusiness process engineer may specify a rule as:

-   -   A means of scheduling an activity (wait until a condition holds        true)    -   A pre-condition to an activity    -   A means of determining the most appropriate user to whom an        activity should be assigned    -   A means of setting a default value for an attribute    -   A condition under which an attribute will be hidden (security)    -   A condition under which an attribute will be protected        (security)    -   A means of reversing an update to an attribute when the value of        an attribute on which it is dependent is modified.        There are different stages at which to apply a business rule        (taking into account any settings as described above). For        example (not to be limiting, but for purposes of clarity), these        stages may be at:

On the commencement of an activity (Pre-activity)

During an activity (Mid-activity)

When the user submits an activity for completion (Post-activity)

On commencement of a transaction (Pre-transaction)

On completion of a transaction (Post-transaction).

Pre and post-transaction business rules are defined as being part of thetransaction, not external to it, and therefore inherit the sameproperties as transactional integrity and consistency. Whenpre-transaction rules are executed, they do so in the context of thepreviously committed values of each attribute and not the values asspecified within the current activity.

The order of processing of an activity transaction is:

Lock all attribute values referenced by the transaction

Execute pre-transaction business rules

Assign package values of each attribute to the database

Execute post-transaction business rules

On success commit (and release locks); otherwise roll back.

Mid-activity business rules are applied whenever a user changes thevalue of the attribute against which the rule is defined or whenever auser changes the value of any attribute on which that rule is dependent.For example (not to be limiting, but for purposes of clarity), amid-activity business rule might be associated with a “Date Of Birth”attribute to the effect “The Date Of Birth must be earlier than today'sdate”. This business rule would be applied to the attribute whenever theuser changed the date of birth and moved the cursor away from thatattribute. As a further example, a package might be establishedconsisting of “Stock Item”, “Quantity” and “Cost” fields. A businessrule might be associated with the “Cost” attribute to the effect “Costequals Unit Price of Stock Item multiplied by Quantity”. When the usermodifies the attributes on which the “Cost” business rule is based(“Stock Item” or “Quantity”) the business rule would be applied and theupdated cost would be displayed on the screen. The “Cost” business ruleis also dependent on the “Unit Price” attribute however in this examplethis would be a display only attribute and hence could not be modifiedby the user. Rules applied as mid-activity business rules will bere-applied when the activity is submitted for completion. This needs tobe done in case, in the meantime, another user changes the value of anyof the attributes on which a rule is based.

The order in which business rules are executed is determined based onthe dependencies of each business rule. For a business rule to beprocessed correctly it is important to execute that rule only afterexecuting all rules on which the rule is dependent. For example (not tobe limiting, but for purposes of clarity), a package may contain fourattributes: A, B, C and D (where A, Band C are display only) with thefollowing associated business rules:

A=B+C+D

B=D*4

C=D/2

The order of execution would be set as follows:

B=D*4

C=D/4

A=B+C+D

Following the execution of any part of a business rule that assigns anattribute's value, further execution of the rule is suspended to allowfor the execution of any business rule that is dependent on theattribute being assigned. Any such business rule may itself be suspendedfor the same reason. Once the business rules of the dependent attributeshave been executed, execution of the original business rule is resumed.There is no limit on the number of rules that can be suspended at anyonetime. This approach could lead to a cyclical reference scenario wherebyexecution might never end. To prevent this, a business rule that iscurrently suspended will not be allowed to execute a second time. Thefollowing example is based on an “Invoice Number” attribute whichcontains a cyclical reference but is nonetheless a valid business rule:

If the Invoice does not have a Invoice Number then

Assign the Invoice Number=the Next Invoice Number

Assign the Next Invoice Number=the Next Invoice Number+1

otherwise

Verify the Invoice Number is less than 1000

This business rule is dependent upon both the “Invoice Number” and “NextInvoice Number” attributes. During execution of this business rule,after each assignment statement, execution would be suspended in orderto execute any dependent business rules. As a dependent of itself, thisbusiness rule would not be re-executed even though in this particularcase it would not result in an endless loop. However, if the rule wererewritten as follows, re-execution would result in such a loop:

If the Invoice does not have a Invoice Number then

Assign the Next Invoice Number=the Next Invoice Number+1

Assign the Invoice Number=the Next Invoice Number

otherwise

Verify the Invoice Number is less than 1000

Given that either of the two variants will not be re-executed, the rulewould still need to be rewritten if it were to serve the purpose ofalways verifying an invoice number was less than 1000. Splitting thebusiness rule into two rules as follows would achieve the correctresult:

Verify the Invoice Number is less than 1000

If the Invoice does not have a Invoice Number then

Assign the Invoice Number=the Next Invoice Number

Assign the Next Invoice Number=the Next Invoice Number+1

In this case, during execution of the latter rule, after the firstassignment statement, execution of the rule would be suspended and theverification rule would be executed as a dependent. If a rule fails, allbusiness rules and transactions would be rolled back.

When a business rule contains conditional logic, the condition will notbe pre-evaluated in order to determine the correct execution order forthe business rules. This is because the evaluated results of theconditions may change as each rule is executed. This may mean that thecorrect execution order cannot be determined. In these cases, thebusiness process engineer will be given a warning and may elect torewrite the rules in question in order to remove any ambiguities.

The business rules are written according to a business rule grammarengine found in the VE Enterprise Interpreter, which is part of the VEPlayer. The grammar defines the structure and meaning of the rule thatcan be defined. The grammar also contains a sub-grammar based on astandard algebraic and mathematical grammar. From the grammar, thebusiness process engineer can choose a list of valid options at eachpoint through the process of defining a business rule. When the grammarchange the list of valid options will automatically be reconfiguredbased on the new grammar. Associated with the grammar is a correspondingJavaScript Translation grammar and is what generates the applicationwithout syntax errors, being that the grammar engine is fullyencapsulated. This grammar defines the valid JavaScript syntax requiredto translate a business rule into JavaScript just in time for execution.

The business rules created by the business process engineer isconstrained by Business Rule Grammar. The grammar is based on the fourprinciples of validation, calculation, condition and action using acombination of set theory and standard mathematical grammar. The grammaris designed such that it can be expanded and enhanced should the needarise. The engineer also has the ability to specify a time-span duringwhich the rule should be in force. If no time-span is specified then therule will be permanently in force, or at least until the engineerspecifies otherwise. The time-span can be based on specific dates andtimes, such as for example, from January 2002 until December 2002, or itcan be based on organization-based events, such as for example, fromChristmas until New Year. Rules can be categorized according todefinitions created by the engineer. For example, a rule may be placedin a Finance category and a Legal category because the organizationperceives it to have both financial and legal implications. Thesecategories can then be used as criteria when searching for particularrules. The definition of a rule is not converted or stored as “code” butis stored as data.

The process explorer (see FIG. 8) provides a simple and efficient meansfor a business process engineer to create, locate and modify businessprocess definitions. Its structure is based on the hierarchicalstructure. To locate a process, the business process engineer can eitherbrowse through the available applications and process categories or canchoose a “find” option. This “find” option will search all the availableprocesses for a process that matches a process name specified by thebusiness process engineer. The process explorer has three modes ofoperation:

-   -   Organization: This mode allows access to all elements of the        Composer, such as Processes, Attribute Library, Organization        Calendar, Users, Groups, etc.    -   Application: This mode allows access to all elements of the        Composer related to a single application, including Processes        and Attribute Library. It excludes elements such as the        Organization Calendar, Users and Groups.    -   Section: This mode allows access to all elements of the Composer        related to a selected section of the hierarchy. This could be,        for example, the Attribute Library, or a Process Category,        including processes, activities, attributes and rules.

The business process engineer can also specify any organizationalrelationships in which the user is a party, for example, the name of theperson who is the user's supervisor or project manager. The businessprocess engineer, when designing the workflow component of a process,can make use of these relationships. For example (not to be limiting,but for purposes of clarity), a “Leave Approval” activity may need to becompleted by the office manager of the user who initiated a “Request forLeave”. Similarly, a “Timesheet Approval” activity may need to becompleted by the project manager of the user who completed the “RecordTimesheet” activity. In these examples, there would be a link flowingfrom the “Leave Approval” activity to the “Request for Leave” activity,and a link flowing from the “Timesheet Approval” activity to the “RecordTimesheet” activity.

Groups can be used to control access to particular activities andprocesses for more than one user. The business process engineer canchoose to structure groups in ways that best suit the security modelused by the organization. The groups may be structured to model theroles that the organization has created, or the groups may be structuredaccording to categories or types of process and can be nested withinother groups. For example (not to be limiting, but for purposes ofclarity), the organization may define the following groups:

Purchasing Officer

Purchasing Manager

Sales Officer

Sales Manager

Chief Financial Officer

The users in each of these positions would then be allocated to thecorresponding group. Access to a “Raise Purchase Order” activity, forexample, may then be granted to the Purchasing Officer, the PurchasingManager, and the Chief Financial Officer groups while access to theApprove Purchase Order activity might only be granted to the PurchasingManager and the Chief Financial Officer groups. Alternatively, theorganization may define the following groups:

Purchasing Approval Sales

Sales Approval

Users would then be allocated to those groups that cover the activitiesrelevant to their role in the organization. For example (not to belimiting, but for purposes of clarity), the Purchasing Manager would beallocated to Purchasing and Purchasing Approval groups. Access to theRaise Purchase Order activity would be granted only to the Purchasinggroup, while access to the Approve Purchase Order activity may begranted only to the Purchasing Approval group.

Groups can also be defined to belong to other groups. For example, theorganization may require three levels of access, Gold, Silver and Bronzewhereby users allocated to the Gold group automatically should haveaccess to all processes to which the Silver and Bronze users haveaccess. Thus, users in the Gold group would also be added to the Silvergroup, and users in the Silver group would be added to the Bronze group.In this way any user added to the Gold group would automatically haveaccess to any process to which a Silver or Bronze user has access.

Groups can be external to an organization or system. An example (not tobe limiting, but for purposes of clarity), is where the U.S.F.D.A. needsto determine and approve the quality of produce coming into afood-processing factory. The U.S.F.D.A. is not part of the organization,but is used by the VE System as an external group.

Within any organization, there exists a number of relationships on whichworkflow is based. For example, a timesheet may need to be approved bythe staff member's supervisor. The composer provides the ability for abusiness process engineer to add these relationships, specify the user'sinvolved in them and then to specify these relationships as a conditionof the workflow of particular processes. This is how the preferredembodiment deals with both vertical and horizontal escalation of anactivity.

Thus, a web-based application development environment called the VEComposer has been described to allow business process engineers todevelop applications by simply designing application specificationincluding workflow processes, business rules and calendar events. Then,using XML and Java, the VE Enterprise Interpreter, through the VEPlayer, dynamically abstracts, encapsulates and then interprets thespecification in real time and delivers the application to the userwithout any programming requirement imposed on the business processengineers.

The method described above can be stored in the memory of a computersystem as a set of instructions (i.e., software). The set ofinstructions may reside, completely or at least partially, within themain memory and/or within the processor to be executed. In addition, theset of instructions to perform the methods described above couldalternatively be stored on other forms of machine-readable media. Forthe purposes of this specification, the term “machine-readable media”shall be taken to include any media which is capable of storing orembodying a sequence of instructions for execution by the machine andthat cause the machine to perform any one of the methodologies of thepresent invention. The term “machine readable media” shall accordinglybe taken to include, but not limited to, optical and magnetic disks.

This VE blueprint section of the present disclosure, consisting ofparagraphs 00115 through 00362, describes the features and architectureof Visual Enterprise (“VE”) business process modeling and managementsoftware program. The information provided in this blueprint section isillustrative and not limiting to the scope of the present invention. TheVE blueprint provides information regarding certain capabilities, someoptional and alternative, of the method of the present invention. The VEblueprint describes how certain alternate preferred embodiments of themethod of the present invention may operate from a technical point ofview, and how certain alternate preferred embodiments of the method ofthe present invention can be used to develop business applications.

The Visual Enterprise™ Business Process Integration Software Platform(“VE”) provides an environment for the web-based development anddeployment of business process systems. It consists of two majorenvironments:

-   1. The VE Composer™, which allows business process engineers to    model the processes of an organization, its rules and data; and-   2. The VE Player™, which allows staff, management and others    associated with an organization to execute those processes and    access data, according to rules laid down by the engineers.

Business process engineers can engineer solutions using VisualEnterprise without the need for programmers to write code. Further,Visual Enterprise is not a code generator. Visual Enterprise dynamicallyconstructs Web pages based on the process, rule and data definitionsprepared by the engineers. Pages are constructed only when required,ensuring that the solutions are flexible, dynamic and always up-to-date.Visual Enterprise allows the business solution to grow and change, in acontrolled manner, as the organization grows and changes. Control isprovided through release and versioning mechanisms.

The Four Cornerstones: Referring now to the Figures and particularly toFIG. 1, Visual Enterprise is built on four main principles ofapplications development: process, data, rules and calendar.

Process—A business management solution must accord with the businessprocesses employed by the organization and must, therefore, be able tomodel workflow, work allocation and assignment, process escalation andadministration. The use of menu options to implement activities thatmust be undertaken in sequence, and which require the user to be awareof the correct order in which tasks should be undertaken, fails to modelworkflow and is not an acceptable solution.

Data—The data needed for an organization to successfully carry out itsbusiness is a key part of any business management solution. Modelingthis data means defining each data attribute, including properties suchas its type (numeric, text, date, etc) as well as defining associationsbetween attributes. For example, the association between a customer andan invoice, or a staff member and a department, must be defined if theprocesses are to actually reflect the nature of the business.

Rules—Business policies are reflected in the rules that govern thecapture and maintenance of data within the context of each step of aprocess. For example, a manager must approve all orders above aspecified limit.

Calendar—An organization operates under many time constraints. It mustbe aware of at least one time zone, the business/working hours of eachoffice, the public holidays observed in various places and any otherevents relevant to the organization's operations.

These four cornerstones of Visual Enterprise are expanded upon below inthis VE blueprint section. All of the features of Visual Enterprise arebuilt upon one or more of these cornerstones.

The VIE Composer

Historically, application development has involved business processengineers or analysts undertaking business process reviews, collectingrequirements, and collating business rules in order to produce aSoftware Requirements Specification. This specification would then behanded over to analysts to prepare functional and technical designdocuments. A team of programmers and administrators, in turn, would usethese documents to develop a solution. The possibility of errors beingintroduced into the final solution due to omissions, inconsistencies,ambiguities or misunderstandings was extremely high.

Visual Enterprise provides the business process engineer with anenvironment to define and document business processes, data definitions,business rules and a calendar of events. This environment is called theComposer. As the Composer has a Web-based browser interface the businessprocess engineer can use Visual Enterprise from literally any corner ofthe globe. All the engineer requires is a computer with access to theInternet.

The information recorded by the engineer is used directly to constructthe solution, without the need to translate from specifications tosource code and without the need for a parsing or compilation. TheComposer allows the engineer to structure and layout components in afashion that models the way in which the organization might previouslyhave documented its processes and rules. All of this information can beviewed by management or other interested parties in a transparentmanner, as opposed to being hidden away somewhere in computer code. Themain elements of the Composer are:

-   -   A graphical process definition system,    -   An application attribute (data definition) library,    -   A business rule definition system,    -   An organization calendar, and    -   An administration section supporting the security model        associated with engineers and application users.

Entity Hierarchy

The Processes, Data, Calendar, and Rules that Visual Enterprise dependsupon are modeled as a hierarchical set of entities. The four principalentities are supplemented by many other entities, each of which supportsand expands upon the four principals. An overview of this hierarchyalong with a brief description of the entities appears below.Organization—The organization for which the solution is beingengineered.

-   -   Engineers—The business process engineers who are engineering the        applications.    -   Users—The management, employees or other interested parties of        the organization who have been granted access to use the        applications.    -   Groups—Positions or roles within an organization against which        access to a particular process or activity is granted.    -   Calendar—Time zone, working hours, public holidays, reporting        periods and events relevant to the organization.    -   Organization Dictionary—A template of attribute properties,        which can be used to assist the application of standards to        information collected by the organization.    -   Application—A collection of business processes, data definitions        and rules, which together reflect how an organization or        particular section of an organization operates.    -   Attribute Library—A library of attributes defining the        properties of and associations between pieces of information        collected by the organization.    -   Process Category—A collection of related processes used to        assist users in identifying the correct process to initiate.    -   Process—A series of steps performed to complete a particular        operation or function of the organization    -   Activity—A single step in a process. A user may complete an        activity or it may be automated, such as a batch process.    -   Attribute—A piece of information collected by the organization,        such as a Customer Name or Invoice Number.

The Composer presents the information to the engineer according to thishierarchical structure. For example, to view details relating to anactivity the engineer must first choose the application, then theprocess category and the process before being able to select therelevant activity.

The VIE Player

The Player is the Visual Enterprise environment that runs the businesssolutions engineered using the Composer. The Player, like the Composer,has a Web-based browser interface allowing users access to theorganization's business processes via the Internet. The main elements ofthe Player are:

-   -   An Intray that presents the user with a list of activities to be        completed. Each of these activities is one step of a business        process that has already been initiated.    -   An OutTray that allows the user to view details of activities        already completed by that user.    -   A New Processes facility for authorized users to initiate new        processes.

When the user opens an activity the Player dynamically constructsbrowser-based forms with the appropriate attributes and associatedlabels. All relevant business rules, including validation andcalculations, are constructed dynamically and built into the page. Boththe Player and Composer have in-built security to ensure only authorizedusers and engineers have access to specific activities within theorganization's processes, data and rules.

This section looks at the four Visual Enterprise cornerstones ofProcess, Data, Rules and Calendar in detail.

Processes

A process is a collection of related activities in a defined workflow.Each process has one initiating activity. This activity may be initiatedeither by a user or by an event. Users must have access rights in orderto initiate a process. Examples of events that could trigger a processinclude: a time constraint, such as a process which must run at 10:00 pmeach night; or a condition being satisfied, such as a process which mustrun once stock gets below a certain level. The workflow determines theorder in which activities are undertaken. Some activities may be able tobe undertaken in parallel, which is controlled by the way thatactivities are linked and associated with each other and the placementof process synchronization conditions (Activity Link Join Methods).

-   -   Activities: An activity is a collection of one or more related        data attribute packages designed to add, update and/or query        data. Rules associated with an activity may be used to validate        data or to calculate values such as totals, tax amounts, due        dates, etc. An activity may either succeed or fail. The success        status is used by the process workflow to determine which        activity or activities are to follow on from the current        activity. A number of different types of activities may be        defined. These include:    -   User Input activities where a user is expected to enter or view        data, such an activity to raise a purchase order.    -   Message activities, which allow a message to be sent to one or        more people, such as an activity to notify a customer by e-mail        that his application has been approved.    -   Report activities, which allow a predefined report to be        generated at a particular point in a process, such as an        activity to print an invoice.    -   Automated activities, which allow data to be processed without        any user input. The selection of data and how it is processed is        based on the definition of the activity created by the business        process engineer.    -   Remote activities, which allow direct access to external        databases.    -   Web Service activities, including both consumer and provider        activities, which allow web services to be integrated into        workflow as part of a standard business process.    -   Maintenance activities, which allow data to be maintained        outside the realms of a standard process, such as an activity to        maintain customer details like phone number, maiden name, etc.

Data: The smallest unit of data in Visual Enterprise is the Attribute.Attributes are defined in collections called Packages, and packages areassociated with each other in various ways. Each Attribute defines thename, data type, size and other properties of the values that will bestored against it. When a package instance is created, attribute valuesare created and stored with a reference back to the package and theattribute within the package. A single package instance consists of oneset of values. There can be any number of instances of a given package.

Packages can be associated in two ways: independent packages can beloosely associated in a relatively ad hoc way, as required for specificprocesses. There is no need to predefine package associations in theLibrary, although that is always a useful option when relatively strong,commonly used associations are defined (e.g. Customer/Invoice). Thesecond type of package association is used where packages are associatedto the point of dependence, for example Line Items on an Invoice. Herethe dependent package would be defined as a Sub-Package. Data in aSub-Package cannot exist independently of the package instance it isdependent upon. When the ‘parent’ is deleted the sub-package data isremoved as well.

Attributes: An attribute defines a collection of values where eachinstance in the collection conforms to the definition provided by theattribute. Each attribute has a number of properties, such as whetherthe attribute represents a date, a number, text, etc; how it should beformatted on the page and in reports; input control options, etc. Eachattribute value, such as a customer's name or birth date, is recordedusing the business processes and activities defined by the businessprocess engineer. The database maintains the complete collection ofvalues for each attribute, together with references to the package inwhich the attribute is defined. No distinction is made as to the contextof an attribute except by the activity that references that attribute.For example, one activity might be defined to record the details of allcustomers, while a second might be defined to record each customer'spurchases. The collection of values of the “customer name” attributewould include a value for each recorded customer as well as a value foreach time a customer has made a purchase.

Packages: a package is a collection of related attributes. For example,a Customer package would be a collection of attributes related to acustomer, such as the customer's name, date of birth, gender, etc. Apackage may also include sub-packages that define data dependent on themain package. For example, an Invoice package may contain an InvoiceItem sub-package. The Invoice would contain attributes for the InvoiceNumber, Date, etc., while the Invoice Item would contain attributes forthe Quantity and Price of each product being purchased.

A package may have a single instance of a sub-package, such as betweenan Invoice and a Dealer package where there can be only one dealer perinvoice. Alternatively, a container package may have many instances of asub-package, such as between an Invoice and Invoice Line where there canbe many Invoices Lines per Invoice.

Data Transactions: Every activity that allows the user to add or modifyattribute values, or that uses business rules to add or modify attributevalues does so via one or more data transactions. The transactions areinitiated once the user chooses the Submit button but only after theactivity has been validated using the associated business rules. Atransaction is initiated for each package included in an activity. Thetransactions are all applied together as a single activity transactionsuch that the integrity and consistency of the whole activity ismaintained. If a single package transaction should fail for any reasonthen the transactions for all packages in that activity will bereversed.

Visual Enterprise transactions will not delete data from the database.This is because of the inherent problems associated with deleting datathat has already been referenced by other activities. Instead ofdeleting data Visual Enterprise will inactivate data such that it cannotbe referenced in new activities.

The business process engineer does not need to be aware of transactionsbecause they are controlled and managed entirely by Visual Enterprise.

Rules: business rules are the policies, regulations and constraintsgoverning the way an organization carries out its operations. VisualEnterprise is concerned with those business rules that are in some wayrelated to, or impact upon, the business processes being developed. Forexample: “the discount must be less than 10%”, or “a purchase order formmust include at least one item”.

Business rules must be satisfied at all points in time unless acondition is applied that specifically limits the time-span during whichthe rule applies. For example, a discount may be offered only oninvoices raised between Christmas and New Year. This rule will hold trueat all points in time, subject to the condition that the discount isonly offered between Christmas and New Year. In other words, VisualEnterprise would reject any attempt to offer a discount outside of thosetime constraints.

It should be recognized that if a rule is applied when data is submittedto the database the only opportunity for a rule to be invalidated iswhen that data is updated or modified. For this reason Visual Enterprisedoes not continually apply rules to ensure that they still hold true.Instead it applies the appropriate rules whenever data is accessed,added, modified or submitted. A rule such as “the customer's age is thedifference between today and the date of birth” is not recalculatedevery day. In theory, at a given point in time the value of the age willnot be correct. However, as soon as the age is referenced by anactivity, either to display the age to a user or to use the age in somecalculation, the rule will be executed to ensure the value is correct.

Calendar: Visual Enterprise allows an organization to define eventsrelevant to the organization. These might include an OvernightProcessing event, an End of Month event, an End of Financial Year event,a Plant Maintenance Shutdown event, etc. The business process engineercan then associate specific business processes or rules with theseevents. This removes the need for systems administrators to schedulebatch jobs for overnight or end of month processing. It also means thatshould the organization wish to change its end of month processing fromthe last day of the month to the last working day this can be done by abusiness process engineer changing the definition of a single event. Infact, this example would only require the engineer to select one optionindicating that if the event fell on a non-working day to move the eventto the previous working day.

The calendar can be divided into five components:

Time Zone—this enables the engineer to select the time zone in which theorganization operates. Visual Enterprise supports multiple time zones.Individual calendars for departments, offices, etc. can be defined, eachwith its own time zone. Visual Enterprise performs time zone conversionswherever they are required.

Working Hours—specifying the standard working hours for an organizationenables Visual Enterprise to know which times are in and which are outof business hours.

Public Holidays—by defining the holidays observed by the organizationVisual Enterprise is able to move events, as specified by the engineer,which fall on a non-working day. Lists of predefined standard publicholidays are available on a country-by-country and state-by-state basis.

Time Spans—an engineer can define the standard reporting periods thatare used by an organization, such as a Financial Year or Sales Period.

Events—engineers can define absolute or relative events and eitherone-off or recurring events. A relative event is one that occurs at aset time-span before or after another event.

Management, staff or other authorized persons of an organization canaccess the business solution developed by the business process engineersby this environment. The Player interface is entirely Web-based, and isaccessed via a pre-allocated URL (for example, http://ve.orgname.com).The home page at this address requires the user to supply a login nameand password in order to gain access to the site. An Administrator withthe appropriate authority creates a login name to grant access to newusers. The initial password is allocated by Visual Enterprise andcommunicated to the user via e-mail. The first time the user logs intothe site he is required to select a new password, which will then beused for all subsequent access to the site.

The InTray: Once verified, the user is directed to the Intray. This pagedisplays a list of the activities awaiting completion. It includes bothnew activities and partly completed activities that the user iscurrently working on. The activities assigned to a user are determinedby the process workflow (as defined by the business process engineers).The engineer can set a number of properties for each activity, whichdictate how each activity should be allocated and assigned. Forinstance, an engineer may specify that the manager of the user whocompleted the previous activity in the process must complete anactivity. An example of this might be a Request For Leave process wherethe manager of the employee requesting leave must approve theapplication. Alternatively, an engineer may specify that an activity canbe completed by any one of a number of users. A call center may have aSupport Call process where an activity can be completed by any one of ateam of technicians. The first available technician can elect to takethe next waiting support call.

The InTray displays a list of activities by name, along with a number ofassociated details including:

-   -   The date the activity was received,    -   The date by which the activity is due to be completed,    -   The user from whom the activity originated (this is the user who        completed the previous activity in the process workflow),    -   A status indicating whether the activity is overdue, due today,        tomorrow, next week, etc.

The user can also add, view, or modify notes entered by users who havecompleted prior activities in the process. Users completing subsequentactivities in the process can, in turn, view these additional notes.Some additional optional features of the InTray include:

-   -   Access to a history of the process of which an activity is part,        including details of who completed each step and the date each        step was completed.    -   Unopened activities are bolded to ensure they are clearly        distinguishable from activities that the user has already viewed        or partially completed.    -   Users can place an activity on hold. This would be a standard        procedure where all of the information required to complete an        activity is not yet available. The business process engineer can        place time constraints on an activity such that if the        information is not entered within a particular time-span then        the process can be escalated.    -   Activities available to a group of users can be reassigned to        the pool should the user decide that he or she is unable to        complete the activity. Activities can be reassigned either by        the user or by an administrator.

To open an activity the user simply clicks on the activity name. UserInterface activities are laid out automatically in accordance with thedefinition constructed down by the business process engineer in thecomposer. The user completes the activity by entering the relevant datafor the required attributes in the appropriate fields. As theinformation is recorded any associated business rules are executed toensure the data is valid and to carry out any calculations required.Once the page is filled out, the user clicks on the Submit button inorder to submit the data to the database. At this point, where required,rules are re-executed to ensure other users have not made changes,subsequent to the original evaluation of the rule, which might affectupon the validity of the data. At regular intervals the Intray isrefreshed to ensure the user has access to the latest list ofactivities. The Intray is also refreshed when an activity is submittedto ensure the completed activity is removed from the list.

The OutTray: When the user completes an activity it is removed from theIntray and moved to the user's OutTray. The user can access the OutTrayfrom a menu at the top of the page. The OutTray will initially displayall activities completed during the current day. To access activitiescompleted earlier the user can either choose to view activitiescompleted on a particular date or search for all activities of aparticular type completed during a specified date range.

As with the Intray, the OutTray displays a list of activities by name,along with a number of associated details including:

The date the activity was completed,

The date by which the activity was due to be completed,

The activity's status at the time it was completed.

The user can also view any notes associated with the process of whichthe activity is a part. This includes notes recorded by users who havecompleted prior activities in the process and notes recorded by userswho have completed subsequent activities in the process. Further, theuser has access to a history of the process of which the activity is apart; including details of who completed each step and the date eachstep was completed.

Initiating a process: As well as completing activities that are a partof an existing process, the Player allows authorized users to initiatenew processes. The New Process page lists all processes to which theuser has been granted access (by the business process engineers). Theseprocesses are displayed in an explorer-like hierarchy based on theprocess categories designed by the engineers.

A preview of the first user interface activity in the process isdisplayed, to ensure that the selected process is the correct one. Onlyprocesses that have a user interface activity as the first activity canbe initiated from the New Process explorer. User interface activitiesare dynamically laid out on the page without any need for the businessprocess engineer to specify the position of each attribute on the page.The properties of each attribute determine the field order, the width ofeach field, whether a data field, multi-line text box, radio buttons orcheck box should be used, the background and foreground colors, etc.Once a the user has opened a new process by clicking the Open button,the process becomes identical to that where the user completes anactivity from the Intray. Upon completion, the activity is added to theOutTray and the process workflow then initiates the next activity in theprocess and allocates it to the appropriate users.

If the user chooses to cancel the activity instead of submitting it thenthe whole process is revoked. In effect this is the same as if theprocess had not been initiated.

Administration: From time to time issues arise that prevent users frombeing able to complete one or more activities. The Composer allows thebusiness process engineer to design the workflow such that if anactivity is not started or completed by a specified date then theprocess will automatically escalate. Should this occur then the activityis automatically removed from the user's Intray and either reallocatedor a new activity initiated in its place. However, there may beoccasions where no escalation has been specified or where it is notdesirable to wait until the due date. For example, if an employee goeson leave without clearing his Intray then the organization may wish toreassign all of the outstanding activities to other users. TheAdministration section allows an appropriately authorized administratorto reassign one or more activities from a user's InTray to another useror group of users. This option can be accessed via the Administrationmenu at the top of the page.

As with the InTray and OutTray the Administration page also allows theuser to view a history of a process of which a particular activity in aparticular user's InTray is a part.

The VE Composer: This is the environment used by business processengineers to define and document the processes, data, rules and calendarused by the organization. The Composer interface is entirely web-based,and is accessed via a URL. This page requires the engineer to supply anorganization ID, login name and password in order to gain access. Theorganization ID is allocated by Visual Enterprise when the organizationis first registered. An administrator or business process engineer withthe authority to grant access to new engineers allocates the login name.The initial password is allocated by Visual Enterprise and communicatedto the engineer via e-mail. The first time the engineer logs into thesite he is required to select a new password, which is then used for allsubsequent access to the site.

After verifying the engineer's details, the Composer page is displayed.This page is divided into three areas:

-   -   The Explorer, which is located on the left-hand side of the        page.    -   The Workspace, which is located on the right-hand side of the        page. When the engineer is not working on a specific process        this workspace allows access to general Visual Enterprise        information, such as tutorials, latest product news, etc.    -   The Composer Menu Bar. The menus on this bar allow access to        features of the Composer, such as the Attribute Library,        Organization Calendar and Administration functions.

The Explorer: The main purpose of the Explorer is to provide a simpleand efficient means for an engineer to create, locate and modifybusiness process definitions. Its structure is based on the VisualEnterprise entity hierarchy outlined above. The Process Explorer hasthree modes of operation, namely: Organization—This mode allows accessto all elements of the Composer, such as Processes, Attribute Library,Organization Calendar, Users, Groups, etc.

-   -   Application—This mode allows access to all elements of the        Composer related to a single application, including Processes        and Attribute Library. It excludes elements such as the        Organization Calendar, Users and Groups.    -   Section—This mode allows access to all elements of the Composer        related to a selected section of the hierarchy. This could be,        for example, the Attribute Library, or a Process Category,        including processes, activities, attributes and rules.

The Process Workspace graphically displays the workflow of a selectedprocess. It can be used to view or modify the flow or to modify detailsabout any of the activities that make up the process.

Activities can be dragged and dropped within the workspace. As theengineer defines each new activity, workflow links can be establishedwith existing activities. In this way the process workflow can bedefined and reviewed before having to specify the attributes, rules andother activity-based properties. Managers or other interested partiescan be granted read-only access to these processes in order to reviewand sign-off on the workflow. This helps to ensure that the processflows are correct before adding the more detailed parts of the processdefinition.

Organization Dictionary: An important factor in any business solution isto provide a consistent user interface. Visual Enterprise facilitatesthis consistency making it possible to define attribute definitiontemplates. These definitions allow the engineer to define attributeproperties such as the data type, a default value, whether or not it ismandatory for a user to record a value for the attribute, etc. Some ofthe properties are specific to a particular data type, such as thenumber of decimal places, which is specific to numeric attributes. Someproperties, while applicable to all data types, have options that aredependant on the data type. For example, the options applicable to theformat properties of a numeric attribute are different from the optionsapplicable to a date or time-span attribute. Attributes defined withineach Organization's template can be grouped into categories for easyreference. When engineers create attributes for a particularapplication, they can choose to base the definition on an attribute fromthe template. In this way the attribute inherits all of its propertiesfrom the template. The engineer may choose to override one or more ofthese properties. Any not overridden continue to be inherited from thetemplate.

For example, a Currency attribute may be defined in the OrganizationDictionary with the following property values as shown in Table 1:

TABLE 1 Property Value Name Currency Data Type Number Control Data FieldDefault 0 Mandatory No Decimal Places 2 Display Width 10 averagecharacters

An engineer may then create, as part of the application, a Discountattribute, which is based on the Currency attribute template. All of theproperties are inherited from the Currency attribute. A furtherattribute, named Price, may be defined and also based on the Currencyattribute. However, in this case the engineer may choose to override theMandatory property to “Yes” and the Display Width property to 12. Allother properties are inherited from the template. If, at a later pointin time, the Display Width property of the Currency attribute is changedto 8 then the Discount attribute will inherit this new value. The Priceattribute, however, will not as its value was overridden.

The use of the Organization Dictionary can greatly reduce the timerequired to define each of the attributes required for an application.It also means that a later change in requirements relating to theproperties of a group of attributes (such as increasing interestcalculations from 2 to 3 decimal places) can be effected with much lesseffort.

Attribute Library: Each application developed using Visual Enterpriserequires an Attribute Library. This library details the attributes thatare collected by the organization as part of its operations. Forexample, an organization collects information about customer names,addresses, phone numbers, purchase order numbers, product names,quantities, etc.

These attributes are grouped into packages of related attributes. Forexample, a Customer package would be a collection of attributes relatedto a customer, such as the customer's name, date of birth, gender, etc.A package may also sub-packages. For example, an Invoice package maycontain an Invoice Item sub-package. The Invoice would containattributes for the Invoice number, date, etc., while the Invoice Itemwould contain attributes for the name, quantity and price of the productbeing purchased. Each sub-package represents a (possibly) multivalueddata group that is dependent on the ‘parent’ package. If an instance ofthe parent is deleted then so are all instances of its sub-packages. Forexample, deleting an Order deletes all its contained Line Items.

Package properties include:

-   -   A list of key attributes that uniquely identify an instance of        the package. For example, a customer's name and telephone number        might uniquely identify each customer.    -   A list of search attributes that are used to assist users when        making a choice from a list of available package instances. For        example, to assist the user in selecting a customer, the        engineer might choose to display the customer's name, date of        birth, and phone number. By defining these as search attributes,        the user can see the values displayed and search by any of them.

Additional properties are maintained on multi-valued sub-packages,including:

-   -   The order in which the package instances should be displayed.        For example, should invoice items be displayed in product code        order or in order of price?    -   Whether there is a minimum or a maximum number of instances. For        example, an organization might require an invoice to be limited        to 10 items or fewer, or not to be limited at all.

Library attributes can be based on the Dictionary or they can be definedfrom scratch. An attribute that is based on a Dictionary attribute canhave the same name as the attribute on which it is based or the name canbe changed as required.

The Business Rule Wizard, or Rule Wizard, allows the engineer to definerules wherever they are needed. For example:

Against an attribute in the Attribute Library.

Against a package in the Attribute Library.

Against an activity in a process.

On a conditional workflow link.

As a search condition to restrict associated package instances.

In a process trigger.

The Composer guides the engineer through the process of defining a rule,step by step. At each step the engineer simply chooses the appropriateoption. The Composer also has two sub-components tailored towardsmathematical and algebraic expressions. Called the Expression Builderand the Condition Builder, these components operate like a calculator.This approach allows these sorts of rules to be defined quicker thanwould be the case with an options-based approach.

The Composer's options are based on the Visual Enterprise Business RuleGrammar. The grammar is based on the four principles of validation,calculation, condition and action using a combination of set theory andstandard mathematical grammar. The grammar has been designed such thatit can be expanded and enhanced as the need arises. The engineer alsohas the ability as part of the Composer to specify a time-span duringwhich the rule should be in force. If no time-span is specified then therule will be permanently in force, or at least until the engineerspecifies otherwise. The time-span can be based on specific dates andtimes or it can be based on organization-based events.

Rules can be categorized according to definitions created by theengineer. For example, a rule may be placed in a Finance category and aLegal category because the organization perceives it to have bothfinancial and legal implications. These categories can then be used ascriteria when searching for particular rules.

The definition of a rule is not converted or stored as “code” but isstored as data. The Player environment accesses this data and theappropriate logic is applied to ensure that the conditions laid out bythe rule are met.

Organization Calendar: The five components of an organization's calendarare all accessed from a common dialog. This dialog contains tabs thatallow the details associated with each component to be defined andmaintained.

Time Zone: The time zone is automatically set based on the country andstate entered by the organization as part of the registration process.If necessary, an alternative time zone can be selected.

The time zone may optionally be used by Visual Enterprise to handle timezone conversion, which may be necessary, either because some users areoperating in a different time zone or the organization is operating in adifferent time zone to the database server.

An organization's work hours will tend to be constant over time. Whenthey change Visual Enterprise maintains both the old working hours andthe new hours. The period of time between the start of new working hoursand the end of those working hours, when a new set is defined is calleda cycle. Features and rules associated with cycles include:

-   -   A new cycle can be defined ahead of time so that there is a        seamless transition from one set of working hours to another.    -   Only details about the working hours for the current (most        recent) cycle can be modified.    -   The working hours for the current cycle can be removed,        effectively re-instating the working hours from the old cycle.    -   A new cycle cannot be defined which comes into effect before the        current cycle.

Most organizations operate on a recurring weekly period whereby, forexample, the working hours may be from Monday to Friday, 8:00 am to 5:00pm. Some organizations will have working hours that are different onsome days of the week. For example, the hours may be Monday to Friday,7:00 am to 3:00 pm and Saturday, 8:00 am to 12:00 am. Visual Enterpriseallows a variety of different configurations, including specifyingnon-working time within a block of working time. The latter could beused, for example, to record meal break times.

Different parts of an organization may have different working hours.Visual Enterprise provides the ability for an engineer to establishseparate but linked calendars for different entities. For example, acalendar might be established for each of the departments within anorganization to cater for the different workings hours betweenmanufacturing, delivery, sales, finance, etc.

Holidays: Whilst public holidays are normally standard fororganizations, there are occasions where staff may be required to workon some public holidays. For this reason Visual Enterprise allows anengineer to choose whether or not to set the standard public holidaysfor an organization. If standard public holidays are set the engineercan still choose to remove one or more of those holidays that may not beapplicable. An engineer can also define additional holidays that may notbe standard for the particular state or country in which theorganization operates.

The standard public holidays need only be set once, and do not need tobe set each year. Visual Enterprise has a definition of each holiday sothat it can calculate the day on which it will fall each year. Should astate or federal government change the date on which a holiday falls itwould be necessary for an engineer to modify the definition of theholiday to reflect that change.

When Visual Enterprise needs to determine whether a particular date is aworking day or not, the organization's defined working hours are firstchecked. If there are no working hours for that particular day then itis a non-working day. If there are working hours defined then VisualEnterprise will check whether that date is defined as a holiday. If itis, then the date is a non-working day.

Time Span: A Time Span defines a recurring time period. There arepredefined Time Spans that cannot be changed (second, minute . . .year). In addition, an engineer can create additional Time Spans such asa 4-week month, or an 8-hour shift. An event is generated each time thetime span recurs. These events can be referred to in rules, and they canbe used to schedule processes and activities.

Administration: From time to time administrative tasks must be performedby business process engineers. These tasks include:

-   -   Registering an Organization    -   Administering security and permissions for Business Process        Engineer    -   Administering security and permissions for users    -   Creating and maintaining access Groups    -   Maintaining Relationships between staff members to reflect the        current organization structure.

In order to begin developing an application with Visual Enterprise, anadministrator or engineer must first register the organization. TheVisual Enterprise home page contains a link to the registration page.This page requires details about the organization, such as theorganization name and address, to be recorded. Details about theadministrator, such as the name, phone number, chosen login name ande-mail address, are also required. Optionally, the administrator canalso register the names of other staff or related parties as VisualEnterprise engineers.

Once the registration is complete, the administrator and any otherregistered engineers are sent an e-mail message containing an allocatedorganization ID, login name and password. As soon as this message isreceived the engineer should log into Visual Enterprise where they willbe required to select a new password.

Engineers or other appropriate persons are granted authority to performcertain tasks or operations within the Composer environment of VisualEnterprise. These include the authority to manage engineers and users,maintain the attribute library, maintain the calendar, and to designprocesses. An engineer may be a business process engineer who designsprocesses or maintains the attribute library, or it may be someone frommanagement who simply wants to be able to view details of existingprocesses and how they have been structured.

Over time an organization may wish to grant new engineers access to theapplications being developed, modify details of existing engineers orrevoke an engineer's access. Each of these procedures can be performedfrom the Engineer List dialog box. The process of adding a new engineeris the same as adding an engineer during the registration process.Additionally, an existing user may need to be granted access to VisualEnterprise as an engineer. It is important when adding the new detailsthat the option indicating the engineer is already an existing user beselected. This prevents having to maintain two sets of details and alsoprevents the user having to remember two login names and passwords.

Users: A Visual Enterprise user is anyone working for or who has aninterest in an organization, and who has been granted access to one ormore of the processes of that organization. The details that need to becollected for a user are similar to those that are collected for anengineer: name, phone number, login name, and e-mail address. Themechanism for informing the user of the allocated login name andpassword are also the same.

The security mechanism that determines the processes to which a user hasaccess, however, are quite different from those for an engineer.Authorizations, particularly in medium to large organizations, areusually based on groups or roles. This makes the process of resettingthe security for a user who has changed role much simpler. Access toparticular activities within a process can be based on specific groupsso that when a user changes roles only the group or groups to which thatuser belongs needs to be changed. The security for that user willautomatically be reset based on the new groups. The engineer can alsospecify any organizational relationships in which the user is a party,for example, the name of the person who is the user's supervisor orproject manager. An engineer, when designing the workflow component of aprocess, can make use of these relationships. For example, a LeaveApproval activity may need to be completed by the Office Manager of theuser who initiated a Request for Leave. Similarly, a Timesheet Approvalactivity may need to be completed by the Project Manager of the user whocompleted the Record Timesheet activity.

As outlined in the section above on Users, Groups can be used to controlaccess to particular activities and processes. The engineer can chooseto structure groups in ways that best suit the security model used bythe organization. They could be structured to model the roles that anorganization has created or they could be structured according tocategories or types of process. For example, one organization mightdefine the following groups:

Purchasing Officer

Purchasing Manager

Sales Officer

Sales Manager

Chief Financial Officer

The users in each of these positions would then be allocated to thatgroup. Access to a Raise Purchase Order activity might then be grantedto the Purchasing Officer, Purchasing Manager and Chief FinancialOfficer groups whilst access to the Approve Purchase Order activitymight only be granted to the Purchasing Manager and Chief FinancialOfficer groups.

Alternatively, an organization might define the following groups:

Purchasing

Purchasing Approval

Sales

Sales Approval

Users would then be allocated to those groups that cover the activitiesrelevant to their role in the organization. The Purchasing Manager wouldbe allocated to Purchasing and Purchasing Approval. Access to the RaisePurchase Order activity would be granted only to the Purchasing group,whilst access to the Approve Purchase Order might be granted only toPurchasing Approval.

Groups can also be defined to belong to other groups. For example, anorganization might require three levels of access, Gold, Silver andBronze whereby users allocated to the Gold group automatically shouldhave access to all processes to which the Silver and Bronze users haveaccess. To this end, as well as the list of Bronze users, the Silvergroup would be added to the Bronze group. As well as the list of Silverusers, the Gold group would also be added to the Silver group. In thisway any user added to the Gold group would automatically have access toany process to which a Silver or Bronze user had access.

Relationships: Within any organization there exist a number ofrelationships on which workflow is based. For example, a timesheet mightneed to be approved by the staff member's supervisor. Visual Enterpriseprovides the ability for an engineer to add these relationships, specifythe user's involved in them and then to specify these relationships as acondition of the workflow of particular processes.

Processes are one of the four cornerstones of Visual Enterprise. TheExplorer provides a hierarchical view of an organization, itsapplications and the processes and activities in each, while the ProcessWorkspace graphically presents process workflow. Visual Enterprise has anumber of different entities, described in detail below, that aredirectly related to a process.

Process Categories: Process categories are like folders that an engineercan use to provide structure to the list of processes that users see onthe New Process page in the VE Player. An organization may have dozensor even hundreds of defined processes. For example, an engineerdeveloping a sales application may define the following process categoryhierarchy:

Customer Relationship Management

-   -   Marketing Campaigns    -   Telemarketing

Transactions

-   -   Purchasing    -   Sales    -   Adjustments

Maintenance

-   -   Customers    -   Suppliers    -   Staff    -   Departments

Reporting

-   -   Monthly Reports    -   Year to Date Reports    -   Whole of Year Reports

All processes relating to purchasing would be defined against thePurchasing category and so on. For an engineer to access one of theseprocesses he would simply need to select the Transactions categoryfollowed by the Purchasing category. Likewise, for a user (who has beengranted access) to initiate one of these processes he would need to makethe same selections.

The security associated with each of the processes in a given categorywill have some similarities. For this reason, Visual Enterprise allowsthe engineer to specify the default access for any process added to thatcategory.

Process Definition: The construction of a process involves a number ofsteps, most of which relate to the definition of the activities thatmake up that process. The initial step is to define the process itself,and its user access. The next step is to add activities to the processand to define the workflow or links that join these activities together.After creating each activity the engineer may choose to define theadditional information that is required to fully build a process.Alternatively, the engineer may choose to leave the detailed informationto a later time, once the links between the activities have beendefined. As each activity is added an icon is added to the ProcessWorkspace to graphically represent each step in the process. Theengineer can position this icon in the Workspace as required to displaythe overall flow of the process. The positioning is a matter of personalchoice. Some may prefer processes to flow from left to right on thepage, others from top to bottom, or a combination thereof. At regularintervals or when the engineer moves to a new process, the graphicallayout is automatically saved to the database. If an icon is moved bymistake then the engineer can choose to refresh the layout from the lastsaved position.

Activity Definition: An activity can be defined as one of a number oftypes:

-   -   User Input activities where a user is expected to enter or view        data, such an activity to raise a purchase order.    -   Message activities, which allow a message to be sent to one or        more people, such as an activity to notify a customer by e-mail        that his application has been approved.    -   Report activities, which allow a predefined report to be        generated at a particular point in a process, such as an        activity to print an invoice.    -   Automated activities, which allow data to be processed without        any user input. The selection of data and how it is processed is        based on the definition of the activity created by the business        process engineer.    -   Remote activities, which allow direct access to external        databases.    -   Web Service activities, including both consumer and provider        activities, which allow web services to be integrated into        workflow as part of a standard business process.    -   Maintenance—where the user can add, modify or delete data in        circumstance which may not fall within any formalized business        process but which, nonetheless, needs to be maintained.

Associated with an activity is a series of information, which can bedivided into a number of groups. Some of this information is dependentupon the activity type, however it includes:

-   -   Attributes—a list of attributes to be displayed, used or        collected by the activity. This list is created by selecting        packages and attributes from either the Attribute Library, the        Organization Dictionary or from a previous activity in the        process.    -   Links—details about the activities that precede and succeed the        activity, including any conditions associated therewith.    -   Rules—a list of rules relevant to the activity, which need to be        enforced by Visual Enterprise.    -   Time Criteria—properties that dictate any time constraints, such        as a completion deadline, that are placed on the activity.    -   Access—a list of groups and/or users to whom the activity has        been granted access. The groups or users granted access to the        first activity in a process determine the users who have the        authority to initiate that process.    -   Initiation—properties that indicate how to determine the user or        users to whom the activity should be allocated.

Visual Enterprise supports a variety of integration techniques. Theserange from low-level external components integrated through rules, toweb services activities. Using the appropriate technique, the engineer,with assistance from technicians familiar with the access techniques anddata structures, can integrate VE processes with virtually any externalprocess or data source.

-   -   External Components provide access to COM+ or EJB components.    -   Web Services provides access to web service providers. Web        service provides can be other systems within the firewall or        external providers. Web service consumers rely on SOAP and XML        to communicate via HTTP with web service providers. VE supports        both web service provider and consumer activities that        seamlessly incorporate these services into a Visual Enterprise        process, as if it was part of the business solution.    -   Remote Activities allow external data sources to be read and        written, as if they were native VE Packages.

Typical examples of remote activities are:

Example 1

An organization may have a legacy system that maintains details of allstaff working for the organization. A process can be developed whichuses a remote activity to provide a user with access to that informationin conjunction with other data stored in the Visual Enterprise database.

Example 2

An organization may have a legacy system that maintains a GeneralLedger. Activities can be developed that access external components topost transactions to that system as part of the business processesdeveloped to raise purchase orders, invoices and receipts.

Example 3

An organization may wish to conduct business-to-business transactionswith a supplier to order stock. A process can be developed that allowsthe organization to place an order with the supplier, including anyrules that might be associated with that order. For example, a rulemight state that if the cost is above a defined limit then the suppliermust seek authorization with the organization before proceeding with theorder. Such authorization would be obtained by the automated initiationof an activity in the relevant user's Intray (as defined by the processworkflow). If the user authorized the cost of the order then thatauthorization would be transported, again via SOAP, to the supplierwhereupon the order could proceed (or be cancelled if authorization wasnot obtained). N.B. For this functionality to operate the remote systemor component must support the SOAP infrastructure.

Process Views: Within any organization, different staff may havedifferent views of exactly what is entailed in any given process. Thismay be because certain steps in the process are not relevant to someusers, or that some information collected or displayed by an activityshould be restricted to certain users. For example, an engineer may havedefined a process to collect information about a new staff member. Thismay include personal details, contact details, payroll details, etc. Theinformation may be collected over a series of activities by differentstaff within the organization. A staff member from the Personneldepartment may initiate the process; the new staff member may themselvesfill in the personal details; and a staff member from the Payrolldepartment may complete the payroll details. The final activity in theprocess may revert to the Personnel department. It may be a requirementof the organization that the staff member's salary not be displayed toanyone in the Personnel department with the exception of the PersonnelManager.

Visual Enterprise allows an engineer to define one or more views of aprocess, which enables the information included in each step of theprocess to be tailored according to the user who has access to thatstep. The engineer must define two components of a view:

-   -   Activity/Attributes—this is a selection of the activities to be        included in the view, and for each activity, which attributes        should be visible to the user.    -   Access—this is a list of groups and/or users who have been        granted access to the view. Being granted access to a view is        quite different from being granted access to an activity. Access        to a view gives a user access to details about the history of a        process, as it relates to the activities included in the view.        It does not, by itself, allow a user to complete any one of        those activities. Access to an activity, on the other hand, does        gives a user the authority to complete that activity no matter        which view is being used.

Every, or each process, may optionally have one default view, whichincludes every activity and those attributes assigned to each activity.Any given user may have access to more than one view of a process. Ifthis is the case then the user is given the option of which view to usewhen initiating a new process or opening an activity.

Neither the links between activities, nor the rules associated with anactivity, nor the time criteria nor assignment properties are affectedin any way by a view.

Attributes: Attributes are one of the four cornerstones of VisualEnterprise and as such it is important to understand the relationshipbetween attributes and packages, attributes and processes, andattributes and business rules.

Cardinality of Package Associations: Associations between attributepackages in Visual Enterprise are described in each directionindependently. If we look at two packages, A and B, then the associationof A to B is described separate from B to A. The complete list ofpossible associations between the two packages is as shown on Table 2 asfollows:

TABLE 2 A → B B → A One-to-one One-to-one (each A has only one B) (eachB has only one A) One-to-many One-to-one (each A has many Bs) (each Bhas only one A) One-to-one One-to-many (each A has only one B) (each Bhas many As) One-to-many One-to-many (each A has many Bs) (each B hasmany As)

There are two ways in which packages can be associated:

-   -   A sub-package/super-package association implies a one-to-one        association from the sub-package to its super-package. That is,        the sub-package must belong to just one super-package. For        example, a Customer may have an Address sub-package. In the        other direction, super-packages can have a one-to-one or a        one-to-many association with a sub-package. For example, a        Customer may have a one-to-many association with an Income        History sub-package. In all cases sub-packages depend for their        identity on their associated super-package. If the super-package        data is deleted then the sub-package data is deleted with it.    -   A linked package is not dependant on another package. Instead,        it defines an association between independent packages. For        example, an Invoice may link to a Customer, and a Loan        Application may also link to a Customer. In this case, a        Customer can exist without any Invoice or Loan Application being        created. Links can be either one-to-one or one-to-many. If the        Invoice or Loan Application is deleted, there is no effect on        the Customer.

Package Associations: Some kind of association exists between mostattributes of an organization. These associations exist betweenindividual attributes and also between packages. For example, a customername attribute is directly associated with a customer phone numberattribute; an invoice number is directly associated with an invoiceitem. These associations are defined explicitly by the way in which theengineer creates attributes within packages. A name and phone numbermight both be defined as attributes under a customer package. Thisimplies a direct one-to-one association. The invoice number might bedefined as an attribute and invoice item as a package, both under aninvoice package. Stock item, quantity and cost attributes may further bedefined under the invoice item package. This implies a one-to-oneassociation between all of the invoice item attributes and also betweenthe invoice number and the invoice item attributes.

Associations are also defined implicitly by the way in which attributesare used within an activity. An invoice activity may include the invoicenumber attribute as well as the customer name attribute. This defines animplicit association between the invoice package and the customerpackage because they are referenced in the same activity. This isdespite the fact there is no explicit association defined between thetwo packages. Typically, an invoice will contain one or more invoiceitems whereas it will contain a single invoice number (a one-to-manyassociation). The business process engineer can define this associationby creating the attributes within a package and specifying that aninvoice may contain many invoice items.

In some cases, a number of different packages and their containedattributes have an association in common with another package. Forexample, a staff member is associated with the office in which theywork; a purchase order is associated with the office from which thatorder originates; a meeting is associated with the office in which thatmeeting is held. In this case, the office package should not beexplicitly defined as a sub-package of each of the star purchase orderand meeting packages as it would not identify the common or sharedassociation that exists in each case. Rather, Office needs to be definedas an independent package, so that it can be referred to, as required,across many activities within various processes.

Packages that are the subject of shared associations should first bedefined as packages independently of the packages with which they areassociated. Once this has been done they can be linked to theirassociated packages. Alternatively, they can be defined implicitly asshared associations within an activity, by the simple fact they arereferenced in common.

When referencing an attribute of a shared association in a businessrule, it is important to fully qualify the attribute to include theassociation. For example, an organization might have a business rulethat indicates the offices in which staff work must have a phone number,however this rule might not apply to offices in which meetings are held.In this case, the following business rule would be too restrictive:

Verify that the Office has a Phone Number.

The rule would need to be qualified such that the association betweenStaff and Office is included:

Verify that the Staff Office has a Phone Number.

Attribute References: When referring to an attribute (for example in abusiness rule), a business process engineer may either be referring to asingle value or a set of values depending on the context. In the contextof a sales order, if the engineer refers to a customer's name he isreferring to a single customer. If, on the other hand, the engineer isdescribing the customers who may place an order then he might refer tothe potential customers' names. This would be referring to allcustomers.

In a natural language, the distinction is made by using the plural formof the noun “name” to distinguish between a single name and a set ofnames. The description above qualifies the name as “customer's name” toindicate a specific reference to the name of a customer as opposed tothe name of a staff member or supplier.

Using Visual Enterprise, “customer” would be defined as a package ofattributes and “name” as an attribute. Visual Enterprise does notdistinguish, in terms of syntax, between a single value and a set ofvalues. All attribute values are part of a set such that a single valueis simply a set that contains only one item. This set of values is knownas a result set. Both attributes and packages have result sets. Anattribute result set is a set of values for that attribute. A packageresult set is a set of values for each attribute of the package. Each ofthese sets must contain the same number of values, although some of thevalues may be null or not specified.

For example, a customer package may consist of a name attribute and aphone number attribute. For each value of the name attribute in thecustomer result set there must be a corresponding value for the phonenumber attribute and vice versa. This does not mean that every customermust have a phone number. For those that do not have a phone number theattribute value will be null (empty, blank).

A fully qualified attribute name is one that includes all of thepackages to which an attribute belongs. For example, “Customer AddressCity” where City is an attribute of the Address package, which is asub-package of the Customer package. To display fully qualifiedattribute names in business rules would overly complicate the reading ofa rule. If there can be no ambiguity over the package to which anattribute belongs then Visual Enterprise will display only the attributename, not the fully qualified name. If there could be ambiguity, forexample because there are two “City” attributes, then Visual Enterprisewill qualify the attribute name sufficiently to remove any ambiguity.

Attribute Result Sets: Business rules are executed within the context ofan activity. This is true even where a rule has been defined in theAttribute Library against a package or an attribute. The attribute orattributes to which a rule refers may or may not be included in theactivity. For example, a rule may be defined against a “Raise PurchaseOrder” activity, which sets the price of the products being purchased.The rule might be:

Assign the Order Item Price=the Product Unit Price

The Product Unit Price may not be one of the attributes listed forinclusion on the activity. This is because the Item Price will bevisible and to display both attributes would duplicate information.

If, however, selection of the price is dependant upon criteria, such asthe date, then these criteria will need to be specified to retrieve thecorrect result set for the product price. If a history of prices existedfor each product then criteria, along the lines of the example below,would need to be added to the rule to uniquely identify the correct unitprice: Assign the Order Item Price=the Product Pricing History UnitPrice where today is between the Product Pricing History Start Date andthe Product Pricing History End Date

Data Retrieval: When an activity is opened any data that has alreadybeen identified, either because it was recorded in an earlier activityor because it has been set by a business rule, is retrieved from thedatabase. Data may also need to be retrieved from the database at othertimes during the completion of an activity. Such a situation would occurwhen:

-   -   The user selects a package instance (such as a Customer) and the        activity definition includes a list of attributes related to        that customer (such as the Name, Phone Number, Date of Birth).    -   A business rule references data not contained within the        activity, in order to perform some verification or calculation.

Attribute Properties: There are a number of properties relating toattributes, which dictate the functionality or rules associated withthat attribute. For example, the engineer can specify that the value ofan attribute must be selected from one of a list of options. Theseproperties include:

-   -   Data Type—such as Text, Number, Date, etc.    -   Control—this property determines the interface between the user        and attribute in the Player environment. Options include Data        Field, Radio Buttons, Check Box, and Drop-down List. Depending        on the value of other properties some of these options may not        be valid.    -   Options List—indicates a list of options from which the user can        choose.    -   Extendable Options—whether or not the user can add additional        items to the Options List.    -   Default—the default value for the attribute.    -   Mandatory—whether or not the user must supply a value for the        attribute.    -   Editable—whether or not the user can modify the value of the        attribute.    -   Visible—whether or not the attribute's value is displayed on the        page.    -   Tooltip—a short description of the attribute that is displayed        when the mouse is positioned over the attribute in the Player        environment.    -   Minimum and Maximum Values—these properties are equivalent to a        business rule that verifies whether the value entered by a user        is greater than a minimum or less than a maximum value.    -   Minimum and Maximum Length (Text Only)—these properties control        the minimum or maximum length of text that a user is permitted        to enter.    -   Decimal Places (numeric only)—the number of decimal places to        which the attribute's values are to be stored.    -   Units (numeric only)—such as miles, gallons, dollars, etc.    -   Background and Foreground color—foreground color is the color of        the text entered by the user while background color is the color        behind that text.    -   Input Format—this property controls the acceptable format for a        value entered by the user. For example, an input format that        specifies two decimal places would prevent the user from        entering more than two decimal places.    -   Output Format—this property controls the format in which values        are displayed. For example, an output format that specified one        decimal place would display the value with only one decimal        place, even though it may be stored to two or more decimal        places.    -   Display Width and Units—these properties control the width        allocated for an attribute on the page. The width refers only to        the attribute value and not the associated label. The units can        be specified as pixels, inches, centimeters and average        character width.

Business Rules: Business rules are another component of the fourcornerstones. Each business rule is dependant, not only on thedefinition of the rule, but also on the definition of the attributes onwhich the rule is based and the context in which the rule is executed.There are many types of business rule. The major determinant is the ruletype (logic, verification, assignment, or action), which determines howthe rule interacts with the process in which it runs.

Business Rule Types: Business rules fall into two categories: active orpassive. An active business rule is one that affects the value or stateof a Visual Enterprise attribute, package, activity or process. Forexample, “Assign the Price=the Quantity multiplied by the Unit Price” or“If the Total Price is greater than $1,000 then execute theAuthorization by Sales Manager activity”. The order in which activebusiness rules are applied can be critical to the correct processing ofrules. Visual Enterprise automatically determines the correct order,based on logical dependencies between the rules. A passive business ruleis a business rule that performs some verification or validation andresults in either a success or failure. For example, “New accounts canonly be opened where the customer has provided proof of identification”.The order in which passive business rules are applied will not affectthe outcome.

Business rules may be associated with activities, packages andindividual attributes. Package and attribute business rules areautomatically associated with each activity in which the attribute orattributes are referenced. The business process engineer may elect toturn off or override such a business rule where it is not applicable toa particular activity.

A business rule may comprise a single statement or it may consist of anumber of statements. In the latter case all of the statements must, incertain preferred embodiments of the method of the present invention, beappropriate in type. For example, a verification statement cannot bedefined in a business rule that also includes an assignment statement.Some business rules may also be specified implicitly via an attributeproperty rather than explicitly as a business rule statement. Forexample, a rule that an invoice number can be no longer than 7characters may be specified as a “Maximum Length” property of anattribute. The fact that a business rule appears as a statement in thisVE blueprint section does not preclude that the functionality may beprovided by Visual Enterprise exclusively as a property.

Business Rule Composition: After creating a business rule, the next stepis to select the type of rule. The rule type determines the type ofstatements that the rule can contain, as per Table 3 below:

TABLE 3 Rule Type Verify that data being entered conforms to this ruleConstraint Select a package Constraint Restrict a package ConstraintSpecify a condition to this rule Logic Assign a value Active Assign adefault value Active

In certain preferred embodiments of the method of the present inventionconstraint and logic rules are passive. The constraint and logic rulesmay optionally be applied to ensure that conditions are met, even wherethe constraint and logic rules are unable to change attribute values.Active rules can change the value of an attribute. The order in whichthe passive rules are evaluated may not significantly affect animplementation of a preferred embodiment of the present invention, butthe order in which active rules are evaluated can be important becauseactive rules often calculate a value based on other attribute values,which may in turn be affected by other active rules. If the sequence inwhich the rules were evaluated was allowed to change then the outcomecould be different.

To prevent inconsistencies that arise from changes to the evaluationorder, Visual Enterprise determines rule dependencies automatically.(Please note the section on Execution Order for more details.} Logicrules include variants such as “if . . . then . . . otherwise . . . ”and “based on the value of . . . if it equals . . . ”. Repetitionvariants, such as “while . . . do . . . ” or “repeat . . . until . . .”, are also available. Verification or validation statements test acondition and either report an error or warning or perform some otherspecified action. A restriction statement restricts the availablechoices that a user can make to ensure the choice is valid for theparticular circumstances.

Assignment statements can be further categorized into:

Attribute assignment—assign a value or expression to an attribute.

Package assignment—set an instance of a linked package based onspecified criteria.

Action statements include those to:

Retrieve data from the database.

Initiate a process.

Schedule a process that has been initiated but not yet commenced.

Initiate an activity.

Schedule an activity that has been initiated but not yet commenced.

Allocate an activity to a group or a particular user.

Create an audit trail.

Execute an external process.

External processes may be referenced by any of the types of statementdetailed above. For example, an external process may be required tovalidate a credit card number; it may be required to retrieve anexternal document, which is then assigned to an attribute; or it may berequired to send a message to a telephone pager. An external process, ifit were to be included in a transactional rule, would need to providetransactional integrity and consistency by means of methods to begin,commit and rollback a transaction.

Visual Enterprise makes a distinction between errors resulting fromhardware or software deficiencies and exceptions raised as a result ofthe processing of business rules. An example of an error might include:

-   -   A hardware failure, such as the server crashing, insufficient        disk space or a telephone line dropping out.    -   A software failure, such as the browser crashing or the        operating system hanging.

An example of an exception might include:

-   -   A data-based exception where a value of an attribute, as entered        by the user, does not satisfy one or more business rules; or    -   A time-based exception where an activity is not completed within        a specified period.        Should an error occur, Visual Enterprise attempts to report the        error to the user, allowing the user to take whatever remedial        action is required. If possible, Visual Enterprise logs an entry        and/or send an e-mail message to an administrator detailing the        nature of the error. Any further processing of business rules        for that activity is cancelled. Business rules already processed        within the transaction; during the processing of which the error        occurred, are rolled back.

Business rule exceptions can be described as either internal or externalto an activity. An internal exception is one where control of theactivity remains with the user allowing the user to modify an attributeor attributes such that the verification rules are met. An externalexception is one where the activity is automatically cancelled andcontrol flows to the activity scheduler via the failure route for thatactivity. Most exceptions can be detected and handled during data entrybefore the commencement of the processing of a transaction. However, ifthis is not the case then the entire transaction will be rolled back toensure the integrity and consistency of the database.

In the case of an external exception, the handling of the exception istaken outside the control of the user to whom the activity was assigned.The business process engineer is able to define a complete workflow tobe followed for each defined exception. This workflow may include anescalation of the exception should further data or time constraints notbe met by the allocated user or users. If both an internal and externalexception were to occur within an activity Visual Enterprise wouldimmediately allow the workflow activity scheduler to deal with theexternal exception. Any data entered for the activity in error would bepassed to the “Exception” activity however it would not be committed tothe database. This would allow the user handling the exception to eithercorrect that data, where required, or to reset and then re-enter thedata

The business processes being defined may also require warnings to beissued to users at various stages. Visual Enterprise provides thisfunctionality via a variation on the verification/validation businessrule definition. This variation would indicate a warning was to beissued rather than raising an exception. In this case, processing wouldcontinue normally once the warning had been issued. Such warnings wouldoptionally be issued before any data being committed to the database.

Attribute Associations: One of the defining differences between VisualEnterprise and other application development environments is the wayassociations between various attributes are defined. Although VisualEnterprise is built on a standard relational database, the engineer seesassociations within the context of the packages, activities andprocesses in which they are referenced. This affects both on the storageof data and the way such data is retrieved. For example, in continuingthe invoice activity example, which has been used earlier in thisdisclosure, the following attributes may be included:

Invoice Number

Invoice Date

Customer Name

Customer Phone Number (display only)

Customer Address (display wily)

Multiple invoice item attributes

This activity might be used to enter a new invoice. Visual Enterpriseneeds to be able to determine how and when to retrieve the customer'sphone number and address. This is done through the definition ofpackages and key attributes.

In the above example, the business process engineer would specify thatthe invoice detail attributes were part of the main or controllingpackage. The invoice item attributes would be part of a separate InvoiceItem repeating package to allow multiple items to be entered. TheInvoice Number would be defined as the key attribute for the mainpackage.

The customer package and therefore the customer attributes (name, phonenumber and address) would be linked to the main package. This wouldindicate a one-to-one association from the invoice to the customer (anda one to many association from the customer to the invoices). Fordetails on how the customer phone number and address are retrieved referto the section below on Data Retrieval.

Data Consistency: As a multithreaded, multi-user system, VisualEnterprise must ensure that data is consistent across processes. It isalso possible for an engineer to define inconsistent rules. VisualEnterprise detects such inconsistencies and ensures that they areresolved before the application is used.

Process Interactivity: Visual Enterprise only stores the latestsubmitted version of an attribute's value. This means that one processmay modify the value of data created by an activity of a second processwhile that second process is still in progress. For example, consider aninvoice entry process that consists of two activities, one to enter theinvoice details and a second to approve the invoice, each step to beperformed by at least two different users. When a user completes thefirst activity, the invoice details are submitted to the database.Before the next user (e.g., a supervisor) has the chance to approve theinvoice, a third user (e.g., a manager) may run a separate process tomodify invoice details. If this manager submits changes to the sameinvoice before the supervisor begins the approval activity then thesechanges will be presented as the invoice details to be approved.

If the supervisor has commenced the approval activity but not submittedwhen the manager submits the changes to the invoice detail then thesechanges will not be presented to the supervisor. Visual Enterprise will,however, notify the supervisor that the data has changed so that he canrefresh the data before approving the invoice.

If the supervisor had approved the invoice before the manager tried tomodify the invoice details it would be left to the business processengineer to decide whether this was a valid activity or not. It may be abusiness rule of the organization that approved invoices cannot bemodified but can only be cancelled.

Ambiguous Rules: It is possible for a business process engineer todefine conflicting or ambiguous business rules. For example, one rulemay be defined offering a discount on certain products at a certain timeof year. Another rule may be defined which provides a discount to loyalcustomers. Does this mean that loyal customers receive an additionaldiscount if they purchase the specially discounted products or do theysimply receive the greater of the two discounts?

Visual Enterprise optionally detects conflicting and ambiguous businessrules and prompt the engineer to redefine the conflicting rules or toclarify the ambiguity. This will be done when an engineer chooses topublish an application by searching for rules that apply to the sameattribute or attributes. It will then generate a conflict resolutionform that must be completed before the application can be published.

For example, suppose the following separate business rules were defined:

-   -   If the Order Date is between Halloween and Christmas Eve and the        Product Type is equal to Sports Goods then        -   Assign the Discount=10%    -   If the Customer Status is equal to loyal then        -   Assign the Discount=5%

Visual Enterprise would detect that the Discount attribute was beingassigned by two separate rules and that the conditions applied in eachcase may conflict, resulting in an ambiguity. The engineer could resolveany ambiguity by combining the two rules into one. The decision might bethat the sports goods discount takes precedence over the loyal customerdiscount.

If the business wanted to give the maximum discount, catering forsituations where the discount percentages may change from time to timethen the two rules could be combined as follows:

-   -   If the Order Date is between Halloween and Christmas Eve and the        Product Type is equal to Sports Goods then Assign the Sports        Discount=10%    -   If the Customer Status is equal to loyal then Assign the Loyalty        Discount=5%    -   Assign the Discount=maximum (the Sports Discount, the Loyalty        Discount)        If the business wanted the discounts to be cumulative then the        rule would be specified as:    -   Assign the Discount=the Sports Discount+the Loyalty Discount        If no discount applied to a particular purchase order then the        result of the above rule would be a discount of 0.

Data retrieval: A single attribute may be referenced in a number ofdifferent activities and processes. When retrieving data VisualEnterprise uses the context in which an attribute is referenced todetermine the retrieval criteria. In order to retrieve data, VisualEnterprise determines an association list for each attribute within aprocess. This list is based on explicit associations that the businessprocess engineer may have defined as well as any associations implicitin the process definition. An implicit association is one where twounlinked packages have been included in the same activity. This definesan association between the attributes of both packages.

When the value of an attribute is either entered by the user orretrieved by Visual Enterprise the value of any related attributes willoptionally, in turn, be retrieved. Let's extend the earlier example ofthe entry of an invoice to an activity that allows the invoice to bemodified. The invoice number would again be defined as a key attribute.When the user enters an invoice number Visual Enterprise will retrievethe values for any related attributes, in this case the invoice date,customer name and invoice items. The customer phone number and addressare not directly related to the invoice number, as they were not inputin the same activity as the invoice number.

The customer phone number and address are related attributes of thecustomer name because they belong to the same package. As soon as VisualEnterprise retrieved, the customer name (as a result of the userentering an invoice number) Visual Enterprise would in turn retrieve theassociated phone number and address.

When searching for related attribute values more than one instance maybe found which matches the key value. This set of values forms theresult set for the related attributes. The result set may or may not beappropriate for the definition of the activity within which theattribute is being retrieved. For example, a multi-value result setcannot be displayed in a single data field however it can be displayedin a list or table. In this case, an exception would be raised.

Key Attributes: One or more attributes within a package or activity maybe unique. For example, within an activity to record customer detailsboth the company name and business number may be unique. This means notwo companies can have the same name and no two companies can have thesame business number.

Unique attributes in one activity will typically be used as keyattributes in other activities. This is because they guarantee that theresult set for any related attributes, in a one-to-one association, willcontain a single value. When defining activities that reference customerdetails, for example, the business process engineer should be able tointerchange the company name with the business number as and whenrequired. In effect the business number is an alternate key for thecompany name and the company name is an alternate key for the businessnumber.

An attribute that is defined as being unique within an Activity is analternate key for all of the other unique attributes defined in thatsame activity. This alternate key association extends beyond theactivity in which the attributes are defined as unique to any activityin any process. When, for the purpose of retrieving data, VisualEnterprise builds a search-list of activities where both the baseattribute and its key attribute are referenced within the same activity,the search-list will be extended to include any activity where the baseattribute and an alternate key attribute are referenced.

To continue the above example, let's add a Customer ID to the list ofcustomer related attributes. One activity might be defined to collectthe name and ID attributes only (both defined as unique). A secondactivity may be defined (either within the same process or in anotherprocess) to collect the phone number and address, with the ID used asthe key attribute. In this case no one activity references the customername, phone number and address. However, for the purpose of retrievingthe phone number and address, the “Customer Name” attribute's alternatekey, “Customer ID”, can be used as the link between all attributes.

The above approach to data retrieval imposes a methodology on thebusiness process engineer that involves retaining a consistentdefinition of all attributes across all activities and processes. Forexample, if a number of address attributes (street, city, postcode,etc.) were referenced in one activity as a postal address and in aseparate activity as a property address Visual Enterprise would notrecognize the distinction. Separate attributes would need to be definedfor postal and property addresses so that the definition of theseattributes was consistent in all activities. In other words, whereas inthe first scenario an “Address” is sometimes a postal address andsometimes a property address, in the second scenario a “Postal Address”is only ever a postal address and a “Property Address” is only ever aproperty address.

Business rules may need to be applied at various stages of an activityor process. In certain circumstances, the business process engineer willdetermine this stage based on the type or nature of the rule. Theengineer may specify a rule as:

-   -   A means of scheduling an activity (wait until a condition holds        true)    -   A pre-condition to an activity    -   A means of determining the most appropriate user to whom an        activity should be assigned    -   A means of setting a default value for an attribute    -   A condition under which an attribute will be hidden (security)    -   A condition under which an attribute will be protected        (security)    -   A means of reversing an update to an attribute when the value of        an attribute on which it is dependent is modified.

Visual Enterprise will determine the appropriate stage at which to applya business rule (taking into account any settings as described above).These stages are:

On the commencement of an activity (Pre-activity)

During an activity (Mid-activity)

When the user submits an activity for completion (Post-activity)

On commencement of a transaction (Pre-transaction)

On completion of a transaction (Post-transaction).

Pre and post-transaction business rules are defined as being part of thetransaction, not external to it, and therefore inherit the sameproperties as transactional integrity and consistency. Whenpre-transaction rules are executed, they do so in the context of thepreviously committed values of each attribute and not the values asspecified within the current activity.

The order of processing of an activity transaction is:

Lock all attribute values referenced by the transaction.

Execute pre-transaction business rules.

Assign package values of each attribute to the database.

Execute post-transaction business rules.

On success commit (and release locks); otherwise roll back.

Mid-activity business rules are applied whenever a user changes thevalue of the attribute against which the rule is defined or whenever auser changes the value of any attribute on which that rule is dependent.For example, a mid-activity business rule might be associated with a“Date Of Birth” attribute to the effect “The Date Of Birth must beearlier than today's date”. This business rule would be applied to theattribute whenever the user changed the date of birth and moved thecursor away from that attribute.

As a further example, a package might be established consisting of“Stock Item”, “Quantity” and “Cost” fields. A business rule might beassociated with the “Cost” attribute to the effect “Cost equals UnitPrice of Stock Item multiplied by Quantity”. When the user modifieseither of the attributes on which the “Cost” business rule is based(“Stock Item” or “Quantity”) the business rule would be applied and theupdated cost would be displayed on the screen. The “Cost” business ruleis also dependent on the “Unit Price” attribute however in this examplethis would be a display only attribute and hence could not be modifiedby the user.

Rules applied as mid-activity business rules will always be re-appliedwhen the activity is submitted for completion. This needs to be done incase, in the meantime, another user changes the value of any of theattributes on which a rule is based.

Execution Order: The order in which business rules are executed isdetermined by Visual Enterprise based on the dependencies of eachbusiness rule. For a business rule to be processed correctly it isimportant to execute that rule only after executing all rules on whichthe rule is dependent. For example, a package may contain fourattributes: A, B, C and D (where A, B and C are display only) with thefollowing associated business rules:

A=B+C+D

B=D*4

C=D/2

Visual Enterprise would set the order of execution as follows:

B=D*4  (1.)

C=D/2  (2.)

A=B+C+D  (3.)

Following execution of any part of a business rule that assigns anattribute's value, further execution of the rule is suspended to allowfor the execution of any business rule that is dependent on theattribute being assigned. Any such business rule may itself be suspendedfor the same reason. Once the business rules of the dependent attributeshave been executed, execution of the original business rule is resumed.There is no limit on the number of rules that can be suspended at anyone time.

This approach could lead to a cyclical reference scenario wherebyexecution might never end. To prevent this, a business rule that iscurrently suspended will not be allowed to execute a second time. Thefollowing example is based on an “Invoice Number” attribute whichcontains a cyclical reference but is nonetheless a valid business rule:

If the Invoice does not have a Invoice Number then

Assign the Invoice Number=the Next Invoice Number

Assign the Next Invoice Number=the Next Invoice Number+1

otherwise

-   -   Verify the Invoice Number is less than 1000

The exemplar business rule above is dependent upon both the “InvoiceNumber” and “Next Invoice Number” attributes. During execution of thisbusiness rule, after each assignment statement, execution would besuspended in order to execute any dependent business rules. As adependent of itself this business rule would not be re-executed eventhough in this particular case it would not result in an endless loop.However if the rule were rewritten as follows, re-execution would resultin such a loop:

If the Invoice does not have a Invoice Number then

Assign the Next Invoice Number=the Next Invoice Number+1

Assign the Invoice Number=the Next Invoice Number

otherwise

-   -   Verify the Invoice Number is less than 1000

Given that either of the two variants will not be re-executed, the rulewould still need to be rewritten if it were to serve the purpose ofalways verifying an invoice number was less than 1000. Splitting thebusiness rule into two rules as follows would achieve the correctresult:

Verify the Invoice Number is less than 1000

If the Invoice does not have a Invoice Number then

Assign the Invoice Number=the Next Invoice Number

Assign the Next Invoice Number=the Next Invoice Number+1

In this case during execution of the latter Me, after the firstassignment statement, execution of the rule would be suspended and theverification rule would be executed as a dependent. Were it to fail, allbusiness rules and transactions would be rolled back.

Where a business rule contains conditional logic, Visual Enterprise willnot pre-evaluate the condition in order to determine the correctexecution order for business rules. This is because the evaluatedresults of conditions may change as each rule is executed. Even thoughin certain circumstances the results may be consistent, VisualEnterprise will not endeavor to detect these circumstances. This maymean Visual Enterprise is unable to determine the correct executionorder. In these cases the business process engineer will be given awarning and may elect to rewrite the rules in question in order toremove any ambiguities.

Visual Enterprise business rules are based on a purpose-designedgrammar. The grammar defines the structure and meaning of the rule thatcan be defined. The full grammar is outlined in an appendix to thisdocument. The grammar also contains a sub-grammar based on a standardalgebraic and mathematical grammar.

From the grammar, Visual Enterprise is able to determine a list of validoptions from which an engineer can choose at each point through theprocess of defining a rule. Should the grammar change in any way at sometime in the future, Visual Enterprise will automatically reconfigure thelist of valid options based on the new grammar. Associated with thegrammar is a corresponding JavaScript Translation grammar. This grammardefines the valid JavaScript syntax required to translate a businessrule into JavaScript just in time for execution.

Enterprise Interpreter: The Enterprise Interpreter is the engine thatdrives the execution of the processes, activities, attributes and rulesof a Visual Enterprise application. It can respond to actions taken by auser, such as submitting an activity for completion, initiating ascheduled activity at the required time, or responding to a request froman external process.

The Enterprise Interpreter is a multi-threaded environment meaning thatit can handle requests or tasks from multiple users and other sources atthe same time. Once it has serviced a request, it will send a responseback to the client, including an indication of whether the request wasserviced successfully or not.

Player Activity Page: A number of the requests to the EnterpriseInterpreter are initiated from the Player activity page. The majorrequests from this page include:

Initiate a new process.

Open an existing activity from the Intray.

Submit an activity.

Cancel an activity.

When a new process is initiated, the Enterprise Interpreter creates anew process instance, against which is collected a number of relatedproperties, such as the date and time the process was initiated, and theuser who initiated the process. Each process instance may progressthrough different stages:

-   -   Initiated—a process may be initiated either by a user or by an        event.    -   Completed—a process is deemed to have completed when the last of        its activities has been completed.    -   Exception—an exception is deemed to have occurred in a process        when an exception occurs on one of its activities and that        exception prevents the process from completing.    -   Cancelled—a process can be cancelled by an administrator.

At each stage additional properties are collected similar to thosementioned above. The Enterprise Interpreter also maintains data on eachof the activities that are a part of the process, including theapplication data (attributes) collected by those activities.

The first activity in the process is also initiated at this time. If itis a user input activity then the activity is opened and displayed tothe user.

Open an Existing Activity: When the user opens an activity theEnterprise Interpreter retrieves a number of different types of data inorder to display the activity to the user. The Enterprise Interpretermay also record a number of properties relevant to the activity and thestage to which the activity has progressed. An activity can progressthrough the following stages:

-   -   Initiated—this stage occurs either when a new process is        initiated or when a previous activity in the process is        completed.    -   Allocated—this stage represents the allocation of the activity        to a group of users, which may occur as soon as the activity is        initiated. If the activity is scheduled then this stage will not        occur until the scheduled date and time.    -   Assigned—this stage occurs when the activity has been assigned        to a single user. If the assignment properties of an activity        identify a single user then the activity is assigned as soon as        it is allocated. If, on the other hand, the properties identify        a number of possible users then the activity is assigned when        the first of those users opens the activity.    -   Started—this stage indicates that the activity has been opened        by a user or that an automated activity has commenced        processing.    -   Incomplete—an activity can be saved by a user whilst incomplete        if he does not have sufficient information or time to submit the        activity.    -   On Hold—a user can place an activity on hold if the information        required to complete an activity will not be available for some        time.    -   Completed—this stage occurs when a user successfully completes        an activity or, in the case of an automated activity, when the        activity has finished processing.    -   Exception—this stage is reached if an exception occurs which        prevents the activity from being completed. This may be because        the user has not completed the activity by a completion        deadline.

At each of these stages, properties relevant to the stage are recordedin the database. These properties are similar to those recorded for thedifferent stages of a process and together they present a workflowhistory of the process.

The information or data that the Enterprise Interpreter needs toretrieve when an activity is opened includes:

-   -   The list of package, attributes and associated properties        included in the activity definition.        -   Details of all of the business rules that apply to the            activity.    -   The application data that has already been recorded in previous        activities.        This information is used to build the activity page that will be        displayed to the user. It will also be used to validate data        recorded by the user and perform any calculations thereon.

When the user submits an activity all of the data entered by the user ispassed to the Enterprise Interpreter. It is the role of the EnterpriseInterpreter to process each of the business rules associated with theactivity, and if there are no errors, to submit the data to thedatabase. Once this has been done, the activity is progressed to thecompleted stage. The Enterprise Interpreter also determines whetherthere are any activities that should follow and if so it initiates thoseactivities. If any of those activities is allocated to the usersubmitting the former activity then the Enterprise Interpreter willautomatically open that activity for the user. This allows a seamlessworkflow whereby the user is not required to always return to the Intrayin order to open the next activity in the process. If the user is notready to complete the new activity then it can be cancelled or savedincomplete.

Cancel an Activity: To cancel an activity means that the completion ofthe activity is temporarily cancelled, not permanently. The activity canonly be permanently cancelled by canceling the entire process. To dootherwise would contravene the workflow requirements designed by thebusiness process engineer. When an activity is cancelled, it remains inthe user's Intray and must be completed at a later time. Any dataentered by the user since the activity was opened will be discarded andno business rules will be executed. The Enterprise Interpreter may notbe required to perform any processing when an activity is cancelled.

Enterprise Interpreter Engine: The first task to be completed by theEnterprise Interpreter for any request is to verify the authenticity ofthe request. The data sent to the Enterprise Interpreter with anyrequest must include the organization, user and session keys. TheEnterprise Interpreter sends these keys to the client browser or remotedevice when the user logs into Visual Enterprise. The organization anduser keys are hidden keys allocated by Visual Enterprise when theorganization is registered and the user granted access. They are nevercommunicated to users or engineers. A new session key is allocated byVisual Enterprise each time a user logs in. Likewise, this is a hiddenkey not communicated to users or engineers. Further, the session key isallocated using a one-way encryption algorithm, such that it cannot be“guessed” by someone trying to gain unauthorized access to anorganization's processes or data

Mode of Operation: The general operation followed by the EnterpriseInterpreter when a user logs into Visual Enterprise to open and completean activity is described in the steps below. Note that variousexceptions and options will cause deviations to these general steps.

-   -   1. The user logs into Visual Enterprise and a session key is        returned to the browser or remote device. It is stored as a        hidden object not visible or accessible to the user. The login        request is made to the server via ASP pages and the Execution        Mode Process Server. The session key is used in all future        communications with the Enterprise Interpreter. The reader may        assume that the session key will be checked using the Security        Processor for all communications, although this will not be        described in the following steps to avoid complicating the        discussion. Similarly, references to the ASP pages and the        Execution Mode Process Server will be restricted to points where        these add significant functionality; generally all traffic flows        through these components and this can be assumed.    -   2. The Intray page is displayed upon receipt of a successful        login. The Intray page on the client requests all active        activities allocated to the current user. The Activity Sequencer        handles all requests for details of activities and processes to        which the user has been granted access. The list of processes is        displayed when the user chooses the New Process option. To        reduce download times, new processes are grouped under        categories and only the processes of selected categories are        displayed.    -   3. From the Intray the user may select a new activity, a        previously opened activity, or an activity placed on-hold. The        request for an activity is passed to the Execution Mode Process        Server, which will coordinate other components as follows:        -   If the request is for a new process then control is passed            to the Activity Sequencer to create a new Process Instance.            The first activity of the new process is identified at which            point processing continues along common lines for both new            and existing activities.        -   Control is passed to the Activity Sequencer to retrieve            various details and properties of the activity including the            attribute names, default values, the screen controls to be            used, and the order in which the attributes are to be            displayed. The Activity Sequence may also be required to            progress the activity to the Started stage if it is not            already. This will prevent other users from being assigned            to the same activity.        -   The Data Coordinator is the next component to get control.            This component retrieves any data that is to be included in            the activity and that has been recorded earlier in the            process.        -   Control then passes to the Rules Processor to process any            pre-activity rules. Such rules may pre-populate attribute            values with a default value, such as today's date. The Rules            Processor also builds, for return to the client browser or            remote device, the JavaScript translations of any            mid-activity business rules identified as being able to be            processed on the client.        -   Finally, control passes to the Response Coordinator to build            the HTML and JavaScript page definition, which will allow            the user to complete the activity.    -   4. As the user records values for each of the attributes on the        page a number of mid-activity business rules may need to be        processed. There are three distinct types of rules that can be        triggered during the completion of an activity prior to the        activity being submitted:        -   A rule that retrieves data from the database for the purpose            of providing the user with a list of options; typically be            triggered by the user clicking a “Find Button” or expanding            a drop-down list A request is made to the Enterprise            Interpreter to process these rules.        -   A rule that involves only data already available on the            page. Entering or modifying the value of an attribute on            which the rule is dependant would trigger this. Such rules            can be processed within the client browser or remote device            so no request is made to the Enterprise Interpreter.        -   A rule that references data not available on the page.            Again, entering or modifying the value of an attribute would            trigger this type of rule. A request is made to the            Enterprise Interpreter to process these rules.            No data is added to or modified in the database during this            processing. Only the values of attributes on the page are            updated.    -   5. When the user presses the Submit Button, a request is sent to        the Enterprise Interpreter to submit the activity. The request        is passed to the Execution Mode Process Server, which will        coordinate other components as follows:        -   Control is passed to the Activity Sequencer to retrieve            various details and properties of the activity.        -   The Rules Processor is invoked to execute all of the            business rules associated with the activity, including those            already processed by the client        -   If no exceptions are raised then control is passed to the            Data Coordinator to submit the data to the database.        -   The Activity Sequencer then gets control, firstly to            progress the activity to the completed stage. At this point            all updates to the database are committed. The Activity            sequencer then determines whether there are any subsequent            activities to be initiated. If any of these activities are            dependent on a condition then the Rules Processor will be            invoked to test that condition.        -   Finally, if one of the new activities has been allocated to            the current user then the Response Coordinator is invoked to            build the HTML and JavaScript page definition for the new            activity.    -   6. The new activities that have been initiated will be visible        in the Intrays of the relevant users allocated to each activity.    -   7. Either the next activity will be displayed or the user will        be redirected to the Intray. The process can then repeat from        step 3.

Active Server Pages: The Active Server Pages serve as an interfacebetween the client browser and the Enterprise Interpreter. The ASP pagespresent the data that comes from the Enterprise Interpreter in a wayacceptable to the client browser, including packaging data into XMLfragments where required. Only minimal processing occurs in ASP pages.These pages invoke the Enterprise Interpreter components.

Response Coordinator: The role of the Response Coordinator is to formata response to requests relating to activities from the client browser orexternal device. The response is in the form of an XML fragment, whichincludes all of the relevant information requested. For example, theactivity data component of such a fragment would be structured as shownin FIG. 22.

The Response Coordinator formats a number of different types of data:

-   -   Activity Definition—including relevant activity, package and        attribute properties. These properties include details about the        display width of an attribute, its input and output formats,        etc.    -   Business Rules—JavaScript translation of all rules to be        executed on the client as the user enters data, as well as        references to all rules that must be executed on the server.    -   Activity Data—as shown above.    -   Validation Errors—details of any errors that may have been        detected during server-side execution of business rules.

The nature of the response to the client is also dependant upon the typeof request. These include request to:

-   -   Preview an activity—only the Activity Definition needs to be        included in the response.    -   Open an activity—the Activity Definition, Business Rules and        Activity Data all need to be included in the response.    -   Execute rules—the response is only in terms of a success or        failure or the rule(s) with details of any errors being        included.    -   Submit an activity—this involves the same response as per        executing rules and, depending upon workflow, it may also        include that required to open a subsequent activity.

No distinction is made in the response in relation to the device fromwhich the request originated. The format of any response is the samewhether the request came from a client browser or from any form ofexternal device, such as a hand-held device.

The Rules Processor: The Rules Processor controls all aspects of thedetermination, translation and execution of business rules. It can becalled upon to perform a number of tasks:

-   -   Prepare all aspects of an activity pertaining to business rules.    -   Execute a rule or list of rules associated with an activity.    -   Execute a condition associated with a particular link between        two activities in the workflow.    -   Execute selected rules relating to specific tasks, such as the        setting of time criteria or the determination of the assignment        of an activity to a user.    -   Execute a condition associated with a data-based event.

The preparation of an activity involves retrieving the list of rulesthat apply to the specified activity and determining the trigger pointfor each of these rules. Some may need to be triggered when an activityis loaded, others when the user changes the value of a particularattribute or when the activity is submitted.

Once the trigger points have been calculated, the Rules Processor makesa determination on whether each rule can be executed by the clientbrowser or whether the nature of the rule requires execution to beperformed by the server. The latter will be required whenever the rulerefers to one or more attributes that are not included on the activity,and hence not available to the client.

The Rules Processor is also required to determine the correct executionorder and dependency list for all rules. The algorithm used to do thisinvolves calculating the attribute dependency list for each rule andensuring that a rule that assigns or modifies the value of an attributeis ordered before any rule that references that attribute.

Before any rule can be executed, it must be translated to JavaScript.This translation is always performed Just-in-Time. The definition ofJust-in-Time is different depending on whether the rule is to beexecuted on the client or on the server. For server-side execution, therule is literally translated just in time for it to be executed.However, for client-side execution, the rule is translated to JavaScriptwhen the request is made to open an activity. The translation ispackaged up with other data by the Response Coordinator and returned tothe client browser. The translation is done at this time for performancereasons, so that control does not need to be returned to the server toexecute such rules. This greatly improves performance, as VisualEnterprise is able to make use of the normally under-utilized anddedicated processing power of client processors.

The final task of the Rules Processor is to execute rules. This involvescalling on the JavaScript Interpreter to execute each translated rule,making available to it the value or values of any attributes the rulemight reference. The Rules Processor also takes the results of theexecution, whether that be successful or not, and returns them to theEnterprise Interpreter. At this point the processing will vary dependingupon the nature of the request:

-   -   For a submit request, if the processing was successful then any        assignments will be taken by the Data Coordinator to be stored        to the database. If the execution of one or more rules resulted        in an exception then the details of that exception will be taken        by the Response Coordinator and returned to the client.    -   For a mid-activity request, all assigned values will be taken by        the Response Coordinator and returned to the client. Details of        any exceptions will similarly be dealt with.    -   For the execution of a specific condition or rule, the results        are returned to the Enterprise Interpreter to control the        processing of workflow or other processing.

Activity Sequencer: The Activity Sequencer performs several functionsrelated to activities. Where a response is required, the data will bepackaged in an XML fragment. Functions performed by the ActivitySequencer include:

-   -   Retrieve a list of activities to be included in the user's        Intray.    -   Retrieve a list of process categories to which a user has        access.    -   Retrieve a list of processes, for a selected category, to which        a user has access.    -   Create a new Process Instance. A process instance is an        instantiation of the process being initiated. When the Activity        Sequencer creates a new instance it also identifies the first        activity of that process to be initiated. Other activities in        the process are not initiated until all preceding activities        have been completed. Depending on the flow of the process, or if        the process is cancelled, some activities may never be initiated        for a particular process instance.    -   Allocate an activity to a user or groups of users who have been        granted access.    -   Assign an activity to a user. This assignment is based on        options specified by the business process engineer. One of those        options is to assign the activity to the first user who opens        it.    -   Mark an activity as completed.

If there are events dependant upon the initiation or completion of anactivity then the Activity Sequencer will invoke the Event Scheduler toinitiate those events. Such events include:

-   -   A start deadline for an activity—the Activity Sequencer requests        that such events are cancelled when the activity has been        started before the deadline.    -   A completion deadline for an activity—the Activity Sequencer        requests that such events are cancelled when the activity has        been completed before the deadline.    -   A scheduled time for the activity to start    -   Other events, which are relative to the initiation or completion        of an activity.

Data Coordinator. The role of the Data Coordinator is to retrieve, add,modify or delete application data. It can be called upon to perform anumber of specific tasks:

-   -   Retrieve all of the data associated with a particular activity        instance. This includes retrieving data submitted by prior        activities of the process as well as retrieving the default        values of any attributes not yet recorded.    -   Retrieve specific data associated with the instances of a        particular package. For example, retrieve a list of customers,        including the customer name, date of birth, social security        number, etc.    -   Retrieve data associated with a specific instance of a        particular package.    -   Add data associated with a new instance of a particular package        to the database.    -   Update data associated with an existing instance of a particular        package in the database.    -   Remove data associated with an existing instance of a particular        package in the database.    -   Retrieve data linked to an existing instance of a particular        package from the database. For example, retrieve the pricing        history of a particular product.

The Data Coordinator must deal with differing versions of data. It mustcater for the fact that the value of an attribute requested by anactivity may not exist. This may be because the attribute itself did notexist when the data associated with the selected package instance wasfirst added. For example, a customer may not originally have defined aphone number attribute. Details of any customers added to the databaseat the time will therefore not have a phone number, even thoughsubsequently a phone number attribute is added to the package Dependingupon the options selected by the business process engineer, if no phonenumber exists the user may either be required to enter one before beingable to submit changes to the customer details or may be able tocontinue without one.

Event Scheduler. The Event Scheduler accepts requests to initiatetime-based events and to cancel time-based events. The scheduler willplace all events into an event queue in sorted date/time order. Detailsrecorded in the event queue include:

The type of event.

The date and time the event will occur.

The action to be performed when the event does occur.

The Activity Sequencer and the Services Queue are the primary sources ofevents.

Enterprise Monitor: Users can initiate processes and activities via theIntray or New Process options. Processes and activities may also beinitiated as a result of time-based and data-based events. These eventsinclude:

A scheduled time has been reached

A signal from an external source that Visual Enterprise is monitoring isdetected

Data meets a pre-defined rule.

The Enterprise Monitor is used to initiate processes or activities basedon events rather than user control. Examples include end of monthprocessing and workflow exception handling when activities are notcompleted within a specified time.

The Enterprise Monitor continually scans the Event Queue waiting for thespecified date and time to arrive. Data-based events are added to thequeue with the current date and time to ensure they are processedimmediately. The queue contains details of the action to be taken whenthe event occurs. Possible actions include:

Initiate a process

Initiate an activity

Raise an exception on an activity

Initiate a service, such as printing a report.

The Enterprise Monitor is also responsible for detecting data-basedevents. A databased event is one that occurs when a condition based onone or more items of data is met. For example, “Initiate the StockOrdering process when the Stock Quantity drops below a pre-definedthreshold”. Continually testing these conditions would, be an intensiveoperation. Visual Enterprise will only test these conditions wheneverany attribute referenced in the condition has been modified. Once thecondition is met the event will be added to the Event Queue and handledby the Enterprise Monitor as outlined above. Some activities will submitoperations to the Services Queue, such as printing, waiting for remoteevents or file operations. These activities may require a confirmationbefore starting the next activity. Once the Enterprise Monitor receivesthis confirmation it will initiate the next activity via the ExecutionMode Process Server.

Services Queue: Visual Enterprise has a transaction server at its corethat receives requests to perform operations. The transaction mustensure the consistency of the underlying data and hence cannot allowmultiple accesses to the same data while an update is occurring. To keepdata consistent, it is necessary to guarantee that only one activityupdates any given piece of information. To reduce the chance of aconflict, a transaction must occur in the smallest possible time.

To avoid any long operation from tying up the transaction engine,operations such as loading remote data, sending entails, and printingare performed outside the main transaction. These are submitted to theServices Queue. If an activity relies on the outcome of the ServicesQueue operation then the Enterprise Monitor will be notified of theoutcome and the process can be progressed accordingly.

Security: Visual Enterprise deals with a variety of different types andmodels of security. Each one is designed to handle a specific purpose.For example, user authentication is used to ensure that only valid userscan log into the site, session authentication is used to preventunauthorized users gaining access to the site via means commonlyreferred to as “hacking”, while the secure sockets layer is used toprotect the privacy of an organization data as it is transported acrossthe internet between a user and the Visual Enterprise server.

Registration: The registration process is designed to allow anorganization to grant access to authorized business process engineersand users. It generates an Organization ID, which is one of the threepieces of information required by a user or engineer to gain access tothe site. As well as incorporating the first five characters of theorganization name, it includes a component that is randomly generated togreatly reduce the risk of an unauthorized user being able to guess theID.

A registered organization may optionally also allocated a unique key,not communicated with engineers or users, which is used as part of thesession authentication process. As part of the registration process,access may be granted to the administrator (who has registered theorganization) to enable him to grant access to engineers and users.

The registration process may also prevent or impede an individual ororganization from “squatting” on the name of another organization. Itdoes so by allowing any number of organizations to be registered withthe same name. Only the unique Organization ID, and not the OrganizationName, is used when gaining access to Visual Enterprise, or whenundertaking business-to-business or business-to-customer transactions.

User Authorization: User (and Engineer) authentication revolves aroundthe three authenticators: Organization ID, login name and password. TheOrganization ID is explained in the section above on registration. If anorganization would like to allow users to log into the Player withouthaving to specify the Organization ID, then an administrator can set upa secure web site that allows this to happen. The organization can placeits own security measures on that site (on the organization's ownserver) to prevent unauthorized access. That site would require the userto supply the login name and password and then transmit those details,along with the Organization ID (built into the page) to the VisualEnterprise site.

Only those engineers authorized by the organization can grant access tonew engineers and users. When such access is granted the engineerdetermines the login name, thus ensuring it conforms to a companystandard. Only the same authorized engineers can change this name.

Visual Enterprise generates the initial password for all engineers andusers when access is granted to an engineer or user. At this time, thethree pieces of information, Organization ID, login name and passwordare communicated to the engineer or user via e-mail. As soon as theengineer or user logs into the site he or she is required to change thepassword to one of his or her choosing. The password may be randomlygenerated to reduce the risks associated with an administratorallocating a password that is commonly known across the organization.The use of e-mail to transport this information is an efficient methodthat reduces the risk of the details being written on paper whencommunicated via the telephone.

Session Authentication: Every time the engineer or user chooses anoption, or enters data that requires the client browser to communicatewith the Composer Server or Enterprise Interpreter, Visual Enterpriseoptionally verifies that the session is authentic. Visual Enterprisedoes so by checking three pieces of information against sessioninformation stored on the server.

Firstly, Visual Enterprise verifies that the organization key, allocatedwhen an organization is registered and stored in the client browser whenthe user logs into the site, matches that stored on the server. This keyis never communicated to a user or engineer and could not accurately beguessed.

Secondly, Visual Enterprise verifies that the user key, allocated whenthe User is granted access to Visual Enterprise and stored in the clientbrowser when the user logs into the site, matches that stored on theserver. This key is never communicated to a user or engineer and couldnot accurately be guessed.

Finally, Visual Enterprise verifies that the session key, allocated whenthe user logs into the site and stored in the client browser, matchesthat stored on the server. This key is never communicated to a user orengineer and is constructed using a non-reversible encryption algorithm.Every time the user logs into the site a new session key is generated.

These three checks provide a triple level of session authentication.

Secure Sockets Layer: Visual Enterprise implements the Secure SocketsLayer (SSL) version 3.0 protocol, a security protocol that providescommunications privacy over the Internet. The protocol allowsclient/server applications to communicate in a way that is designed toprevent eavesdropping, tampering, or message forgery and uses digitalcertificates for authentication.

The primary goal of the SSL Protocol is to provide privacy andreliability between two communicating applications. The protocol iscomposed of two layers. At the lowest level, layered on top of areliable transport protocol (e.g., TCP), is the SSL Record Protocol. TheSSL Record Protocol is used for encapsulation of various higher-levelprotocols. One such encapsulated protocol, the SSL Handshake Protocol,allows the server and client to authenticate each other and to negotiatean, encryption algorithm and cryptographic keys before the applicationprotocol transmits or receives its first byte of data. One advantage ofSSL is that it is application protocol independent. A higher-levelprotocol can layer on top of the SSL Protocol transparently. The SSLprotocol provides connection security that has three basic properties:

-   -   The connection is private. Encryption is used after an initial        handshake to define a secret key. Symmetric cryptography is used        for data encryption (e.g., DES, RC4, etc.)    -   The peer's identity can be authenticated using asymmetric, or        public key, cryptography (e.g., RSA, DSS, etc.).    -   The connection is reliable. Message transport includes a message        integrity check using a keyed MAC (Medium Access Control).        Secure hash functions (e.g., SHA, MD5, etc.) are used for MAC        computations.

The goals of SSL Protocol v3.0, in order of their priority, are:

-   -   A. Cryptographic security—SSL is used to establish a secure        connection between two parties.    -   B. Interoperability—Allows programmers to be able to develop        applications utilizing SSL 3.0 that will then be able to        successfully exchange cryptographic parameters without knowledge        of one another's code.    -   C. Extensibility—SSL seeks to provide a framework into which new        public key and bulk encryption methods can be incorporated as        necessary. This will also accomplish two sub-goals: to prevent        the need to create a new protocol (and risking the introduction        of possible new weaknesses) and to avoid the need to implement        an entire new security library.    -   D. Relative efficiency—Cryptographic operations tend to be        highly CPU intensive, particularly public key operations. For        this reason, the SSL protocol has incorporated an optional        session caching scheme to reduce the number of connections that        need to be established from scratch. Additionally, care has been        taken to reduce network activity.

Digital Certificates: Digital Certificates are based on public/privatekey technology (PKI). Each key is like a unique encryption device. Notwo keys are ever identical, which is why a key can be used to identifyits owner.

Keys always work in pairs, one called the private key, and the othercalled the public key. What a public key encrypts, only thecorresponding private key can decrypt, and vice versa. Public keys aredistributed freely to anyone who wants to exchange secure informationwith you. Your private key is never copied or distributed and remainssecure on your computer or server.

Digital certificates automate the process of distributing public keysand exchanging secure information. When you install a digitalcertificate on your computer or server, your computer or web site nowhas its own private key. Its matching public key is freely available aspart of your digital certificate posted on your computer or web site.When another computer wants to exchange information with your computer,it accesses your digital certificate, which contains your public key.The other computer uses your public key to validate your identity and toencrypt the information it wants to share with you using SSL technology.Only your private key can decrypt this information, so it remains securefrom interception or tampering while traveling across the Internet.

Database Security: Access to the Visual Enterprise database isrestricted to only two sources. That is:

-   -   Access to engineers and users through the Visual Enterprise        Composer and Player environments.    -   Access to the database administrators who installed and maintain        the Visual Enterprise database.

The database administrator configures the account names and passwordswhen the database and Visual Enterprise are installed on the databaseand web application servers. They are not stored anywhere in the VisualEnterprise source code or in any other file controlled by VisualEnterprise. Standard network and firewall security can prevent access tothe server by unauthorized persons.

Process Security: The business process engineers granted access by anorganization to Visual Enterprise have complete control of the users whoare granted access to each process. Users will not even be aware of theexistence of processes to which they have not been granted access. Formore information on Process Security, refer to the sections above inthis VE blueprint section on Users, Groups, Processes, Process Views andActivities.

Attribute Security: Visual Enterprise gives the ability to a businessprocess engineer to set attribute level security in one of two ways:

-   -   A process view can be defined, which restricts access to        particular attributes to specified users or groups. For more        information, refer to the section earlier in this VE blueprint        section on Process Views.    -   A business rule can be defined which changes access to an        attribute based on the current user or group to which he or she        belongs. For more information, refer to the section earlier in        this VE blueprint section on Business Rules.

From the outset, Visual Enterprise has been architectured with a classicN-tier component model in mind. The practical consequences of thisapproach are that two technologies are well suited for implementing thecomponents that together comprise Visual Enterprise:

Microsoft's Distributed Network Architecture (Windows DNA)

Sun's J2EE specification and associated component models.

The first production version of Visual Enterprise has been implementedusing Windows DNA, with a J2EE version to follow. More recently, focushas shifted from Microsoft's DNA to Microsoft's .NET strategy. It isintended that Visual Enterprise will follow this trend with theMicrosoft DNA version being replaced with a Microsoft .NET version inthe future.

The Microsoft DNA is straightforward in its approach to designing andconstructing solutions. In reference to the Figures and particularly toFIG. 23, certain preferred alternate preferred embodiments of the methodof the present invention can and should be partitioned into thefollowing areas, to obtain an optimum design in terms of ease ofmaintenance and scalability.

The specifics of how Visual Enterprise is implemented within .NET arecontained in the following sections:

Presentation Services;

Business Logic; and

Data Services.

Presentation Services include all areas of a solution that provide auser interface. Microsoft's suggested approach is that in new solutions,all presentation services should be web based. Business Logicencompasses all areas of a solution that implement logic or rulesspecific to the solution. Microsoft recommends that business logicshould be implemented using a reusable, stateless component technology,such as COM+. Data services include all areas of a solution that storeor provide data. This includes database, email and directory servers.

In reference to the Figures and particularly to FIG. 23, a firstimplementation of Visual Enterprise, as diagrammed in FIG. 24, hasclosely adhered to the DNA strategy. This is apparent in the high-levelsystem architecture diagram of FIG. 24.

Client Requirements: Two distinct classes of user exist within theVisual environment: Engineers and Users. As detailed earlier, engineersuse the Composer interface for designing solutions, and users use thePlayer interface to run existing solutions. By design, all a userrequires to utilize Visual Enterprise is a reasonably optioned IBM PCwith Microsoft Internet Explorer (version 5.5 or above). Engineers havethe additional requirement of needing to accept a one-time download ofseveral ActiveX controls, used in the composer user interfaces.

A Visual Enterprise client application exists wholly within MicrosoftInternet Explorer, making use of the following technologies to produceuser interfaces and interact with the presentation services:

Hypertext Markup Language (HTML)

-   -   All web pages are rendered using standard HTML.

Dynamic Hypertext Markup Language (DHTML)

-   -   Significant use is made of the dynamic behavior of HTML to        provide flexible user interfaces. The intention has been to use        DHTML to build user interfaces similar to what can be achieved        with client-server techniques.

ActiveX Controls

-   -   The Composer interface makes use of a number of ActiveX controls        (e.g. tree control, flowchart control) to give a more flexible        user interface The Player makes use of the Microsoft XML Parser        control, which is made available though the Microsoft Internet        Explorer installation.

JavaScript

-   -   JavaScript is the main procedural language for utilizing both        DHTML and the ActiveX controls. Also, all client side logic is        implemented using pure JavaScript.

Extended Markup Language (XML)

-   -   XML is used on the client for two purposes: for temporary        storage of structure data, and for communication between the        client and presentation services. Visual Enterprise has a large        number of internal schemas designed for these purposes. The use        of these schemas allows Visual Enterprise to manifest user        interfaces more akin to a client-server implementation without        the client installation overhead.

Presentation Services: The Presentation Services consist of severalhundred Active Server Pages (ASPs) running under Microsoft InternetInformation Server (version 5 or above). These pages respond to requestsfrom the client and determine the HTML, client side JavaScript and/orXML required to answer the request. The following technologies are usedby the presentation services:

JavaScript

-   -   JavaScript is the main procedural language for utilizing both        custom COM+components and the ActiveX controls. All presentation        services logic is implemented using pure JavaScript.

ActiveX Controls

-   -   The presentation services make use of server-side ActiveX        controls to perform operations not specifically available        through the ASP interface or JavaScript (e.g. a control is used        to extract documents from multi-part HTML requests). The        Presentation Services also make use of the Microsoft XML Parser        control, which is made available though the Microsoft Internet        Explorer installation.

COM+Components

-   -   The Presentation Services access the required business logic via        public COM+interfaces, exposed by the business logic layer.

Extended Style Sheet Language Transformation (XSLT)

-   -   XSLT is used to transform internal player XML screen definitions        to the required HTML and client-side JavaScript. The        Presentation Services contain master XSLT style sheets used to        produce all Player user interfaces. Currently these style sheets        are fixed, but is intended that future Visual Enterprise        releases will allow these style sheets to be engineer or even        user defined.

Business Logic: The Business Logic consists of fifty custom-written COM+components and one custom-written service. These components encapsulateall the business logic implemented in the Visual Enterprise application.Microsoft Visual C++ (version 6) has been the language of choice toimplement these components. Due to the nature of Visual Enterprise, thecomponents are the result of hundreds of thousands of lines of verycomplex source code.

The Business Logic implements a database independent layer that allowsVisual Enterprise to be deployed on either Microsoft SQL Server 2000 orOracle 8i Release 2. The database independence is achieved byabstracting all database operations required by Visual Enterprise to asingle COM+ interface, with the given COM+ component having theknowledge of how to interact with the target database.

Integration with third-party systems is achieved through the businesslogic layer. This is achieved using web services constructed usingMicrosoft C# and the Microsoft .NET framework. The traditional COM+components interact with web services using standard SOAP techniques.

The business logic makes use of one or more of the followingtechnologies:

Common Object Model (COM)

-   -   The Common Object Model is a technology developed by Microsoft        for building components that expose interfaces that can be        accessed in a language-independent way. For example, a COM        component can be accessed from Visual C++ and Visual Basic.

Common Object Model+ (COM+)

-   -   COM+ is an environment for hosting COM components. COM+ provides        enterprise services to COM components (i.e. transactions,        queuing, object pooling, connection pooling,        publisher/subscriber event model) via components implementing        standard COM interfaces. All Visual Enterprise business logic        components make use of these services.

ActiveX Data Objects (ADO)

-   -   ActiveX Data Objects are a Microsoft technology that present a        universal way to access data sources of any type. Visual        Enterprise uses ADO to access the underlying Oracle or SQL        Server database.

Microsoft Message Queue (MSMQ)

-   -   Microsoft Message Queue allows transactions to be queued and        processed in the background. COM+ allows components to be marked        as queued, and therefore all requests on the given component are        handled asynchronously. Visual Enterprise makes use of these        features for all background processes, including report        production, automated activities, and event handling.

Collaborative Data Objects (CDO)

-   -   Collaborate Data Objects are a Microsoft technology for        accessing SMTP (email) servers on the local network. Visual        Enterprise uses this technology for dispatching

Microsoft Scripting Engine (JavaScript)

-   -   The ability to execute JavaScript in Microsoft Internet Explorer        is achieved through an ActiveX component called the Microsoft        Scripting Engine. Any application that wishes to execute script        can implement what is called a Scripting Host and invoke the        Microsoft Scripting Engine. Visual Enterprise uses this        technique to execute engineer defined business rules, which have        been previously translated to JavaScript.

Extended Markup Language (XML)

-   -   The business rules layer uses XML to communicate structured data        with the presentation service or with external systems via SOAP.        XML is not used internally in the business logic layer, as small        COM objects have proved more efficient for internal data        communications.

Simple Object Access Protocol (SOAP)

-   -   Simple Object Access Protocol is an evolving technology, based        on XML, which allows services to be accessed over the Internet.        Visual Enterprise uses this technology to integrate with third        party database and systems through the use of web services.

Universal Description, Discovery and Integration (UDDI)

-   -   Universal Description, Discovery and Integration is an evolving        technology for categorizing web services available over the        Internet. Visual Enterprise uses this technology to allow        engineers to search for required functionality (e.g. a credit        card check service) and to use Visual Enterprise's SOAP        capability to include the external functionality natively into        Visual Enterprise solutions.

Crystal Report Designer Component (RDC)

-   -   Visual Enterprise embeds a set of COM components called the        Report Designer Component from Crystal Decisions, which allows        report templates to be dynamically constructed and executed.        This technology is used in conjunction with a custom reporting        user interface to allow engineers to create customized reports        on data contained within Visual Enterprise.

Data Services: Due to Visual Enterprise being a stateless web-basedapplication, all system state and application data must be stored in adatabase. In the case of Visual Enterprise, either a SQL Server orOracle database is required. The database consists of approximately twohundred tables and eighteen hundred stored procedures. The tables can begrouped into three distinct data sets:

-   -   Definitions: 80% of the tables are used to store the details of        Visual Enterprise solutions. Effectively, the composer interface        is a data entry system to correctly fill these tables. These        tables include details of organizations, applications, events,        processes, activities, packages, attributes etc.    -   Metadata: 16% of the tables are used to store metadata. Metadata        at its most simple is data that describes other data. Although        abstract in nature, a concrete example of metadata would be a        library catalog, which contains information about the books in        the library. The contents of the books are unstructured and        varied, but the catalog categorizes the details of each book in        a structured manner. (The same is true of Visual Enterprise,        where engineers using the Composer interface define packages of        data. These packages can then be included in activities in any        manner the engineer sees fit, including the creation of package        relationships on the fly. Visual Enterprise creates metadata to        capture the details of the mapping of high-level packages to        tables in the database designed for storing unstructured data        and the relationships between that unstructured data.)    -   Data: 4% of the tables are used to store the actual data        produced by users accessing Visual Enterprise solutions through        the Player interface. It should be noted that this small number        of tables is likely to be the largest in terms of storage        requirements.

As stated earlier, the Visual Enterprise database contains a largenumber of stored procedures. This allows a database to present ahigh-level interface to the business rules layer, and thus abstracts theneed for the business rules layer to have to deal with the specifics ofone database to another. This is definitely true with SQL Server andOracle, having quite different stored procedure languages and SQLrequirements.

Integration: One of the key selling points of the Visual Enterpriseenvironment is its ability to integrate with other products. From atechnical perspective, Visual Enterprise supports five integrationmethods:

External Components

-   -   Visual Enterprise allows standard COM components to be utilized        as part of the native business rule grammar. This is achieved by        registering a given COM component using the Composer interface.        Visual Enterprise examines that methods implemented by the        components and maps all parameters to native Visual Enterprise        attribute types. The methods are then dynamically added to the        business rule grammar. At business rule execution time, Visual        Enterprise performs the necessary interfacing required to make        remote procedure calls to the relevant external components.

Remote Data

-   -   Visual Enterprise comes standard with a custom web service that        can be deployed against any data source supported by the ActiveX        Data Objects (ADO), which includes any data source that has an        ODBC driver. Through Visual Enterprise accessing the web        service, engineers are able to define “remote packages” based on        tables in data sources supported by the web service. Such        “remote packages” are treated as if they were native data of the        given Visual Enterprise solution. The business rules layer        performs all the necessary mechanics to update the data source        taking into account the data source's referential integrity.

XML Messages

-   -   Visual Enterprise allows custom XML messages to be exchanged        with external systems via the Internet. An engineer can        construct definitions (i.e. using the XML Mapper interface) that        describe how to interpret incoming XML messages and convert them        to native Visual Enterprise packages and attributes, and vice        versa. Again, from the engineer's perspective the XML is treated        as if it were native Visual Enterprise data, with the business        rules layer performing all the mechanics necessary to convert        between the defined XML schema and Visual Enterprise packages        and attributes.

SOAP Messages

-   -   Visual Enterprise supports both the construction of external        SOAP requests and the ability to respond to external systems        making SOAP requests on Visual Enterprise. At its simplest, SOAP        identifies a request XML message schema, a response XML message        schema, and the mechanism for the communication of these        schemas. Using the previously described XML mapping interfaces,        engineers define the structure of both incoming and outgoing        SOAP requests and treat the schemas involved in these requests        as if they were native Visual Enterprise packages and        attributes. Again, the business rules layer performs all the        mechanics necessary to construct, interpret and dispatch SOAP        requests.

Web Services

-   -   Visual Enterprise supports both the consumption of external web        services and exposing Visual Enterprise processes as web        services. The consumption of an external web service is        essentially the same as making a SOAP request. The only        difference is that an engineer can use the composer to search a        UDDI registry to find the required web service. Visual        Enterprise exposes two methods for consuming web services.        Firstly, web services can be registered with Visual Enterprise        in a similar manner to external components and thus used to        extend the native rule grammar. Secondly, a web service can be        used as part of a Visual Enterprise process. The second method        has the advantage of supporting document based web services,        whereas the first method only supports remote procedure call        based web services (i.e. similar to making a call on a remote        component, but in this case using SOAP as the mechanism instead        of Distributed COM). Again, the business rules layer performs        all of the mechanics necessary to construct, interpret and        dispatch web service requests, including the capability for        synchronous and asynchronous processing.

Processes defined through the Composer interface can be exposed aseither a remote procedure call or document based web service. This isachieved by Visual Enterprise exposing a custom end-point to allowexternal systems to communicate back to the given process. From theengineer's perspective, incoming requests appear as native VisualEnterprise packages and attributes, which can be manipulated using allthe power of the Visual Enterprise engine. The business rules layerperforms all the necessary mechanics to receive, interpret, validate,construct and dispatch web service requests.

Scalability: The N-tier nature of the Visual Enterprise implementationallows for both horizontal and vertical scalability to be used to meetspecific performance requirements. The following points detail how eachof the layers can be scaled for increased performance.

Presentation Services

-   -   The Presentation Services layer consists of Microsoft Internet        Information Server web servers. Given Visual Enterprise is        stateless in nature, it is possible (and advisable) to configure        an array of web servers where client requests are dispatched to        the web servers in a “round-robin” or “least-workload” manner.        The number of web servers in the array is only limited by the        network infrastructure used to create the array. As demand        increases, web servers can be added to the array at will.

The maximum throughput for each web server in the array can be achievedby correctly configuring such servers in terms of CPU bandwidth andmemory. The more memory available, the more likely the web server willcache Active Server Pages in memory. It should be noted that theresponses from Visual Enterprise Active Server Pages are highly dynamicin nature, and are not suited to traditional HTTP caching techniques. Infact such caching techniques can interfere with the correct operation ofthe Presentation Services and are usually disabled by default.

Business Logic

-   -   The business logic layer consists, of application servers, which        in practice consist of Windows 2000 Advanced Server configured        with the custom components discussed above. Two options exist        for configuring application servers: each web server can be        statically tied to one application server, or application        servers can be configured in an array, where requests from the        web servers are routed in a “round-robin” or “least-workload”        manner. As with the web servers, creating an array of        application servers allows the business logic layer to be scaled        as needed.    -   The maximum throughput for each application server in the array        can be achieved by correctly configuring such servers in terms        of CPU bandwidth and memory. The custom components are        specifically designed to “read-only” cache static information in        memory, thus reducing load on the data services layer. The        trade-off for this performance enhancement is a greater need for        memory. Also, the custom components perform CPU intensive        operations, especially when dealing with XML documents or the        Microsoft Scripting Engine. Practice has shown that an        application server needs to have approximately twice the memory        and CPU bandwidth to service an equivalent web server.

Data Services

-   -   The data services layer consists of either an Oracle or SQL        Server database. Both Oracle and Microsoft have test cases of        how their products can be scaled from the smallest enterprise        installation up to the largest corporate installation. The        stateless nature of Visual Enterprise has many advantages, but        the trade-off is that more load is put on the database server.        Although this is somewhat mitigated by caching techniques in the        business logic layer, the configuration of a suitable database        server needs to take this into account.

In reference to the Figures and particularly to FIG. 24, certainpreferred alternate preferred embodiments of the method of the presentinvention may comprise a recent Visual Enterprise installation, asdiagrammed in FIG. 24, and how a modest level of scalability can beachieved.

FIG. 24 details a Visual Enterprise installation designed to handle tensof thousands of client requests. The following points detail the path aclient request would follow.

-   -   Requests flow first through a firewall. Both the Internet and        the organization's Intranet are firewalled for security.    -   Requests then flow through a set of switches in failover        configuration. In this case “failover” means that if one of the        switches fails the second switch will take up the load.    -   Requests then flow through a Cisco Load Director, which is a        device designed to route HTTP requests based on a given        algorithm. As mentioned above, Visual Enterprise is best suited        to either a “round-robin” or “least-workload” approach. Again,        the two Cisco Load Directors are deployed in failover        configuration.    -   Requests flow through a second set of switches. Again, the        switches are deployed in failover configuration.    -   Based on the routing algorithm used by the Cisco Load Director,        the request will be routed to one of the web servers in the        array. The given web server will interpret the client requests        and make one or more requests on the application server. It        should be noted that this design has the application servers        statically tied to a given web server. The above design could be        modified to include another layer of Cisco Load Directors and        switches between the web servers and application servers, thus        giving dynamic routing of application server requests.    -   In response to requests from the web server, the application        servers will make one or more requests on the database server.    -   The application server will assemble the details of the response        and forward the response to the given web server.

This VE blueprint section of paragraphs 00115 to 00364 of the presentdisclosure supports an understanding of the methods, models andstructures of a preferred embodiment of the method of the presentinvention comprising the Visual Enterprise™ (VE) business processintegration software platform. This VE blueprint summary describes, in acomprehensive fashion, the paradigm of VE and its purpose is twofold: 1)to outline how VE is architected, and 2) to establish technicalcredibility as to how VE's architecture is realized to employ certainalternate preferred embodiments of the method of the present invention.

VE is a single, unified modeling and execution software environmentsupporting all types of business transactions and processes. VEtechnically enables Business Process Management (BPM); the ability todiscover, design, deploy, reliably execute, scale and optimizeend-to-end complex business processes and transactions.

Creating adaptive models, not code, is the VE paradigm. When businessprocesses change, multiple systems adapt according to certain alternatepreferred embodiments of the method of the present invention thatoptionally comprise VE. VE includes a visual modeling, rules and dataenvironment (VE Composer™) an execution platform, which includesintegration and web services (VE Player™). VE augments existingfunctionality, integrates with various systems, and provides forcomprehensive solutions. VE makes the organization, policies, workflow,calendars and events available directly to system designers and businessprocess experts. VE is built on open standards, such as LDAP, SOAP, SSL,XML, and WSDL/UDDI. VE operates in Microsoft's .NET environment,supports SQLServer and Oracle 9i databases and runs on IE. VE has a‘meta-data’ architecture and can run through most enterprise portals andemail systems.

From the above description and drawings, it will be understood by thoseof ordinary skill in the art that the particular embodiments shown anddescribed are for purposes of illustration only and are not intended tolimit the scope of the invention. Those of ordinary skill in the artwill recognize that the invention may be embodied in other specificforms without departing from its spirit or essential characteristics.References to details of particular embodiments are not intended tolimit the scope of the claims.

1. A method of executing business processes via a computer network, themethod comprising the steps of: creating and installing softwareresources available over a network, the software resources comprisingsoftware resource definitions available through a database of softwareresources; browsing the database of software resources using a processmodel builder to identify the software resource definitions; loading thesoftware resource definitions identified by the process model builder tocreate a business process model comprising the software resources fromthe database of software resources; mapping inputs and outputs of thedatabase of software resources to allow the business process model to beexecuted; saving the business process model on a storage mediumaccessible by the network; and initiating a collaborative businessprocess by loading the business process model into a process interpreterand executing the software resources defined within the business processmodel.
 2. The method of claim 1, wherein the process model buildercomprises a graphical user interface (GUI) business process modelbuilder.
 3. The method of claim 1, wherein the collaborative businessprocess comprises internal and external collaborative businessprocesses.
 4. The method of claim 1, wherein no programming, coding orscripting is required to create the business process model or toinitiate the collaborative business process.
 5. The method of claim 1,wherein the step of executing the software resources within the step ofinitiating a collaborative business process further comprises mappingthe outputs from a first software resource to the inputs of a secondsoftware resource.
 6. A method for dynamically generating softwareresources, the method comprising the steps of: operating a process modelbuilder to load a process definition; defining grammar rules to createan activity; and using the grammar rules in a process workflow model todynamically generate software resources without generating programmingcode.
 7. The method of claim 6, wherein the method further comprises thestep of: using a grammar engine to execute the generated softwareresources.
 8. The method of claim 6, wherein the process definitioncomprises: data attributes; activities referencing the data attributes;processes formed using the activities; business rules applicable to thedata attributes, the activities, and the processes; and locationreferences selected from the group consisting of a universal resourcelocator and a network address.
 9. A computer-readable medium storing asoftware program thereon, the software program operable to: define anorganization calendar for an organization, the organization calendarcomprising attributes applicable to the organization; define businessrules and processes followed by the organization, such business rulesand processes consistent with the organization calendar; define a dataattribute library comprising one or more data attributes for use by theorganization; and define activities performed for the organization usingthe one or more data attributes and at least one of the business rules.10. The medium of claim 9, wherein the attributes of the organizationcalendar comprise time zones, working hours, holidays, and eventsapplicable to the organization.
 11. The medium of claim 9, wherein thedefined activities are constrained by the business rules.
 12. The mediumof claim 9, wherein the defined activities are represented graphicallyon a display operably coupled to the medium as activity icons.
 13. Amethod for generating results of a business workflow, the methodcomprising the steps of: (a) operating a process interpreter todetermine an input data structure required for a software resource to beexecuted; (b) identifying attributes available at run time from anorganization using the process interpreter; (c) mapping the availableattributes to input attributes as defined by a business process modelusing the process interpreter to create an input data structure; (d)forwarding the input data structure to a software resource using theprocess interpreter; (e) executing the software resource using theprocess interpreter to produce an output data structure; (f) providingthe output data structure to the process interpreter for use by theprocess interpreter to complete a process workflow model; and (g)repeating steps (a) through (f) until a final output data structure hasbeen created; (h) returning the final output data structure from theprocess interpreter as results of a business workflow.
 14. A computerreadable medium storing a sequence of instructions thereon, the sequenceof instructions executable to perform a method, the method comprisingthe steps of: operating a network browser interface to obtain aspecification of an application from a network, the applicationcomprising a process model; and dynamically executing the applicationusing the specification without generating programming code.
 15. Themedium of claim 14, wherein the specification comprises: dataattributes; activities referencing the data attributes; processes formedusing the activities; business rules applicable to the data attributes,the activities, and the processes; and location references selected fromthe group consisting of a universal resource locator and a networkaddress.
 16. A system comprising: a network; at least one processor inbidirectional communication with the network; a database of softwareresources stored on a storage medium operably connected to the network,the database of software resources comprising at least one softwareresource; and at least one process model builder available over thenetwork, the at least one process model builder operable to generate abusiness process model using the at least one software resource from thedatabase of software resources.
 17. A system comprising: a network; atleast one processor in bidirectional communication with the network; adatabase of software resources stored on a storage medium operablyconnected to the network, the database of software resources comprisingat least one software resource; at least one business process modelavailable over the network, the at least one business process modelcomprising at least one software resources from the database of softwareresources and at least one process interpreter available over thenetwork, the at least one process interpreter operable to determine adata structure for at least one software resource.
 18. A method ofexecuting business processes via a computer network, the methodcomprising the steps of: accessing at least two software resourcesavailable over a network with a network browser; instructing the networkbrowser to interweave the at least two software resources by operating abusiness process model builder; within a runtime environment, allowing abusiness process model to be dynamically generated in real-time by thebusiness process model builder; generating the business process modelusing the business process model builder by incorporating the at leasttwo software resources interwoven by the network browser into thebusiness process model; and initiating business process activities fromthe business process model to complete collaborative business processesand transactions.
 19. The method of claim 18, wherein the runtimeenvironment comprises a process interpreter and a grammar engine andwherein the runtime environment is network based; wherein the runtimeenvironment encapsulates the at least two software resources necessaryto complete a business process; wherein a workflow determines the orderin which business processes are undertaken; and wherein business processactivities forming the collaborative business processes are linkedtogether according to the workflow.
 20. The method of claim 18, whereinthe runtime environment comprises a process interpreter and a grammarengine and wherein the runtime environment is network based; wherein theprocess interpreter and the grammar engine encapsulated within thenetwork based, runtime environment encapsulates the at least twosoftware resources necessary to complete a business process; wherein aworkflow determines the order in which business processes areundertaken; wherein the collaborative business processes andtransactions comprise internal and external collaborative businessprocesses and transactions; and wherein business process activitiesforming the internal and external collaborative business processes arelinked together according to the workflow.